[Seaside] WARegistry performance

[Levente Uzonyi]

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