[Seaside] WARegistry performance

[Sebastian Sastre]

Hi  Phillipe, I've observed delays on images which are not restarted in a period (maybe weeks).
I'm not sure if the delay is general for rquests or only for session creation.
I didn't see any voting system, I've just posted the note where you referred,
Cheers,
Sebastian

> -----Mensaje original-----
> De: seaside-bounces at lists.squeakfoundation.org 
> [mailto:seaside-bounces at lists.squeakfoundation.org] 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 <leves at elte.hu>:
> > 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
> > seaside at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> >
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside