[Seaside] WARegistry performance

[Philippe Marschall]

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
>