[Seaside] WARegistry performance
ssastre at seaswork.com
Fri Dec 26 13:41:04 UTC 2008
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,
> -----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:
> If anybody else observes this to be a problem is their production
> systems please vote there for it.
> 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
> > 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
> > 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
More information about the seaside