[MAGNOLIA-623] drop HTTP session usage in public instance Created: 20/Jan/06  Updated: 23/Jan/13  Resolved: 01/Nov/07

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 2.1.3
Fix Version/s: 3.5 RC1

Type: Improvement Priority: Critical
Reporter: Andreas Brenk Assignee: Fabrizio Giustina
Resolution: Fixed Votes: 6
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PDF File magnolia-memory-usage-improvements.pdf    
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

The usage of the HTTP session for storing the JCR Session and Magnolia HierarchyManager is a major scalability blocker. I think it would be best to use an object pool of the resources needed for anonymous access to the repository (after verification that it is expensive to create those, if not they should just be created on demand and stored in the request or a ThreadLocal or so.). Anonymous access to the public instance should not create any HTTP sessions.



 Comments   
Comment by Philipp Bracher [ 20/Jan/06 ]

This is understood. Ther first step in this direction is the neutral MgnlContext (thread local) which provides those objects to the magnolia application and core. Different implementations are alowed afterward and therefore a session-less version possible. Since we decided to use spring this will be straight forward.

I'm not sure if we can do all this already for the next release, but if so we would happily accept such a contribution.

Comment by Sameer Charles [ 20/Jan/06 ]

Agreed!

Comment by Fabrizio Giustina [ 03/Apr/06 ]

changing priority to "critical", after the result of a somewhat deeper performance test...

the memory requirements of a public magnolia instance are mostly due to the creation of http sessions.
I recently did some profiling on the 2.1 branch using:

  • Jmeter
  • Jmx client (mc4j) for jmx monitoring (memory, number of sessions)
  • eclipse profiler (TPTP)

Running the same test with Jmeter with disabled/enabled cookie support showed something interesting... testing with 20 groups of 20 thread, with 2 pages requested for each execution (= 800 page requests + 2000 requests for all the static content) showed this result:

  • with cookies disabled (that means that each request is interpreted as a separate sessions): 800 sessions open and memory bumped from 40MB to 375MB in a few seconds
  • cookie enabled (sessions reused for each group): 20 open sessions and memory stable at 65MB max

In a high traffic site this makes a lot of difference, memory usage is at least 500% of what it could be without the need for http session creation. Session timeout is usually in the order of 30 minutes, so a similar number of concurrent sessions is not so high at all... and the worst thing is that memory usage doesn't seem to easily decrease at expiring of sessions...

Comment by Andreas Brenk [ 03/Apr/06 ]

That's exactly the behaviour I observed with jconsole and YourKit after testing a public instance with The Grinder (without cookies, http://grinder.sourceforge.net/). A properly running cache remedies the situation, however.

Perhaps you can get a free "open source project license" for YourKit: http://www.yourkit.com/purchase/index.jsp

Comment by Fabrizio Giustina [ 29/Apr/06 ]

Work done on the 2.1 branch! The attached document show the result of tests perfomed against 2.1.5 and 2.1.6-SNAPSHOT after some tweaking.

This is the list of components involved in the refactoring:

  • SessionAccessControl (the major culprit, now it only stores jcr session in session only if a http session already exists)
  • Authenticator (why storing userid in session also if a user can't login))
  • MessageManager, ContextMessages (never user getSession().getServletContext() only to access a context parameter!)
  • jsps, add session=false to avoid useless session generation
Comment by Sameer Charles [ 26/May/06 ]

hey Fabrizio, have you already ported this to the trunk?

Comment by Fabrizio Giustina [ 26/May/06 ]

I've ported most of the code, but due to the changes in how session, hierarchyManager, messages, ect are stored, I will need to review everything again and probably also change some more things...
Please leave this open until I will be able to run the same tests on 3.x, I will post the results and close the issue if appropriate.

Comment by Fabrizio Giustina [ 01/Nov/07 ]

reviewed and tested for 3.1, no http session is used for anonymous users

Generated at Mon Feb 12 03:19:16 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.