WARegistry performance

> Hi,
>
> Let me answer all questions and issues in one mail.
>
> "Is the creation of dozens of new session a realistic benchmark for a
> typical Seaside application? Do you have a practical use-case where this
> actually matters?"
>
> The answer is no, for a typical Seaside application. We are building a
> drupal-based site which has embedded frames with Seaside applications. So
> every page view creates a new session in some applications.
>
> "The problem is that reaping the expired session requires iterating
> over all the sessions, right?"
>
> It's one part of the problem. The main cause of the problem is that session
> reaping occurs even when there are no session to be reaped. With rapid
> session creation this happens really often (once for every 10 session using
> the defaults).
>
> "Is there any special reason why you don't use dictionary?"
>
> Yes, clustering. Dictionary would work fine if we weren't remove any
> elements from it. We found that sometimes it takes a few seconds to
> unregister the expired handlers, mainly because of Dictionary >>
> #fixCollisionsFrom: takes a lot of time.
>
> "It only works when all the sessions have the same lifetime."
>
> IMO that's the case in most seaside applications, but with slight changes
> sessions can have different lifetime. If sessions expire explicitly, we can
> move their nodes to the front of the list. If we have sessions with
> different timeoutSeconds, say 60, 600 and 6000 for example we can use 3
> separate lists, and still go with O(1) time for housekeeping/session.
>
> If it's really important to support any session lifetime there's a slightly
> different solution. The linked list has to be replaced with a heap. This way
> the cost of registration and unregistration of a session is O(log(n)) where
> n is the number of sessions. It takes O(log(m)) to access a session where m
> is the number of recently active sessions (sessions which are not expired
> and were accessed after the last time this session was accessed).
>
> "If you're at all interested in seeing how your
> changes could be implemented in 2.9 as well, I'm sure that would be
> appreciated."
>
> I don't think that these changes fit into the new design with the plugins.
> Some features can of the plugins could be implemented, others are not really
> useful IMO.
>
>
> We also have a package with the heap based solution which can be found here:
> http://leves.web.elte.hu/waregistry/SeasideRegistry-ul.9.mcz
> If you want to test it:
> - Load HashTable from SqueakSource.
> - Make sure that seaside is not running.
> - Do it: WARegistry clearAllHandlers.
> - Load the mcz.
> - Create the missing instance variables of WARegistry and WAExpiringHandler,
>  the methods in the *seasideregistry category reference them (a changeset
> would be better, i know).
> - Do it: WARegistry clearAllHandlers.
>
>
> While we were creating the heap based implementation we found that the
> original WARegistry doesn't use its mutex in #handleKeyRequest: while
> accessing handlersByKey, which can cause that in a rare case the user's
> request is handled with a different session than the one he/she owns (and
> possibly other issues can occur too).
>
> Any feedback is welcome.
>
> Cheers,
> Levente
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En nombre
> de Philippe Marschall
> Enviado el: Viernes, 26 de Diciembre de 2008 06:08
> Para: Seaside - general discussion
> Asunto: Re: [Seaside] WARegistry performance
>
> I created an issue for this:
> http://code.google.com/p/seaside/issues/detail?id=262
>
> If anybody else observes this to be a problem is their production
> systems please vote there for it.
>
> Cheers
> Philippe
>
> 2008/12/15 Levente Uzonyi <[hidden email]>:
> > Hi,
> >
> > Let me answer all questions and issues in one mail.
> >
> > "Is the creation of dozens of new session a realistic
> benchmark for a
> > typical Seaside application? Do you have a practical
> use-case where this
> > actually matters?"
> >
> > The answer is no, for a typical Seaside application. We are
> building a
> > drupal-based site which has embedded frames with Seaside
> applications. So
> > every page view creates a new session in some applications.
> >
> > "The problem is that reaping the expired session requires iterating
> > over all the sessions, right?"
> >
> > It's one part of the problem. The main cause of the problem
> is that session
> > reaping occurs even when there are no session to be reaped.
> With rapid
> > session creation this happens really often (once for every
> 10 session using
> > the defaults).
> >
> > "Is there any special reason why you don't use dictionary?"
> >
> > Yes, clustering. Dictionary would work fine if we weren't remove any
> > elements from it. We found that sometimes it takes a few seconds to
> > unregister the expired handlers, mainly because of Dictionary >>
> > #fixCollisionsFrom: takes a lot of time.
> >
> > "It only works when all the sessions have the same lifetime."
> >
> > IMO that's the case in most seaside applications, but with
> slight changes
> > sessions can have different lifetime. If sessions expire
> explicitly, we can
> > move their nodes to the front of the list. If we have sessions with
> > different timeoutSeconds, say 60, 600 and 6000 for example
> we can use 3
> > separate lists, and still go with O(1) time for
> housekeeping/session.
> >
> > If it's really important to support any session lifetime
> there's a slightly
> > different solution. The linked list has to be replaced with
> a heap. This way
> > the cost of registration and unregistration of a session is
> O(log(n)) where
> > n is the number of sessions. It takes O(log(m)) to access a
> session where m
> > is the number of recently active sessions (sessions which
> are not expired
> > and were accessed after the last time this session was accessed).
> >
> > "If you're at all interested in seeing how your
> > changes could be implemented in 2.9 as well, I'm sure that would be
> > appreciated."
> >
> > I don't think that these changes fit into the new design
> with the plugins.
> > Some features can of the plugins could be implemented,
> others are not really
> > useful IMO.
> >
> >
> > We also have a package with the heap based solution which
> can be found here:
> > http://leves.web.elte.hu/waregistry/SeasideRegistry-ul.9.mcz
> > If you want to test it:
> > - Load HashTable from SqueakSource.
> > - Make sure that seaside is not running.
> > - Do it: WARegistry clearAllHandlers.
> > - Load the mcz.
> > - Create the missing instance variables of WARegistry and
> WAExpiringHandler,
> >  the methods in the *seasideregistry category reference
> them (a changeset
> > would be better, i know).
> > - Do it: WARegistry clearAllHandlers.
> >
> >
> > While we were creating the heap based implementation we
> found that the
> > original WARegistry doesn't use its mutex in
> #handleKeyRequest: while
> > accessing handlersByKey, which can cause that in a rare
> case the user's
> > request is handled with a different session than the one
> he/she owns (and
> > possibly other issues can occur too).
> >
> > Any feedback is welcome.
> >
> > Cheers,
> > Levente
> >
> > _______________________________________________
> > seaside mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> >
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> > I didn't see any voting system, I've just posted the note where you
> > referred,
>
> Just posting a comment is enough ;-)
>
> Cheers
> Philippe
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>> Can you provide a bit more information? Are the delays only the first
>> few requests or ongoing? What does WASession allSubInstances say? Does
>> WARegistry clearAllHandlers help? How many open processes do you have?
>>
> Sadly, when I waws about to check this, the image already crashed. I have to
> check this later because the recently started image is giving me nearly sub
> second responses now (when all is cached).
> I'll update here as I get some testing feedback,
> Cheers,
> Sebastian
>
>> > I didn't see any voting system, I've just posted the note where you
>> > referred,
>>
>> Just posting a comment is enough ;-)
>>
>> Cheers
>> Philippe
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En nombre
> de Philippe Marschall
> Enviado el: Viernes, 26 de Diciembre de 2008 15:01
> Para: Seaside - general discussion
> Asunto: Re: [Seaside] WARegistry performance
>
> 2008/12/26 Sebastian Sastre <[hidden email]>:
> >> Can you provide a bit more information? Are the delays
> only the first
> >> few requests or ongoing? What does WASession
> allSubInstances say? Does
> >> WARegistry clearAllHandlers help? How many open processes
> do you have?
> >>
> > Sadly, when I waws about to check this, the image already crashed.
>
> Do you have the SqueakDebug.log?
>
> Cheers
> Philippe
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside