On 10/21/08, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Hi all, > > Just out of curiosity, I profiled, my stupid test. And this profiling > revealed an intersting situation > > Without the session pool, logging out is fast. Logging in is not that > fast at all. > > With the session pool, logging in is really fast -- once the pool is > filled with sessions and the pool does not overrun. Logging out a pooled > session, though, is expensive. > > Looking at what is so expensive when logging out pooled sessions, I > found out that executing the query takes roughly 99% of the processing > time of releasing a pooled session ! > > Now, what is this query for ? It finds all locks owned by the user whose > session is about to be released and checks all locks found for whether > they are session scoped or not. This is required to release session > scoped locks to prevent handing these over to next user of the pooled > session. > > Removing the query turns the picture over: running the test with session > pooling is 10 times faster than without the pool ! > > Hmm, looking at these results, I am tempted to say "let's find a way to > prevent the query" ... it's easy: do not use session scoped locks! they only exist for applications that are too lazy to clean up afterwards (with concurrent locks, you need to release your locks, too).
after all, i still think that the session pool should be implemented on the repository level and on on the client level. the repository has all means to optimize and recycle the sessions correctly. keeping a session pool on the client is problematic also in respect to resources. only the repository knows how 'expensive' a session is. having too many 'idle' sessions can kill the performance easily. if we think that the sessions of the repository (i.e. of jackrabbit) are to 'heavy' we should rather focus on making them more lightweight and implement some pooling there. +1 for disabling the session pool per default -0.5 for keeping the session pool regards, toby > > > Hi all, > > > > Sling's support for accessing JCR repositories always included a session > > pool. This session pool dates back some years before Day contributed > > Sling to the ASF at a time, where Jackrabbit and, more importantly then, > > Day's CRX were early release stuff and Session setup was dead slow. > > > > In the meantime, Jackrabbit went through a number of release cycles and > > Session setup time improved a lot. In fact using the Session pool is > > even slower than not using it ! > > > > So, I propose we drop the Session pool from the jcr/base module > > altogether and just keep the (optional) functionality to limit the > > number of simultaneous sessions per user. > > > > WDYT ? > > > > Regards > > Felix > > > > PS: Regarding timing: I did a stupid test of logging in and out 1000 > > Sessions (at most 5 Sessions concurrently open). Running the test with a > > session pool of 10 sessions took roughly 3 times as long as running with > > the pool disabled ! > > >
