[Seaside-dev] Re: Lightweight sessions/contexts/callbacks in 2.9

[Dale Henrichs]

Philippe Marschall wrote:
> 2008/5/24 Dale Henrichs <dale.henrichs at gemstone.com>:
>   
>> Philippe and Lukas,
>>
>> I've been spending some time looking at performance of GemStone/S and
>> Seaside.
>>     
>
> I think this discussion should go to seaside-dev unless there is a
> very good reason against it.
>   
I'll reply to your comments in a separate messge ...
>   
>> As you know, we do one commit per request which puts an upper bound on the
>> number pages we can serve. There is always a limit on the maximum number of
>> commits we can perform in a second, disk speed, the number of objects
>> committed and the speed of the cpu are three of the major gating factors.
>> Recently I was able to get past the disk i/o and number of objects committed
>> barriers, leaving we with the raw commit rate barrier.
>>
>> To get more Seaside throughput, we can look at speeding up the commit rate -
>> there's always room for improvement, but we'd be lucky to get a 25%
>> performance improvement (we've obviously paid close attention to this over
>> the yers).
>>
>> As I was casting about for ideas, I began thinking about the fact that for
>> "read only" Seaside pages, it might be possible to reuse large chunks of
>> session state and as I dug into this farther, I'm convinced that it is
>> definitely possible to reuse nearly all of the session state for both
>> rendering and redirects.
>>
>> I spent the last couple of days implementing "lightweight" sessions against
>> Seaside2.9 and I think I've got something that is very interesting.
>>
>> If you load Squeak-Lightweight-dkh.3 (first) and GemStone-LightWeight-dkh.9
>> (http://seaside.gemstone.com/ss/Seaside29.html) into a (Squeak) Seaside2.9
>> image, you can see what I mean. When you've loaded the packages you will
>> need to configure 'seaside/examples/GemStone/lightweight' to use
>> WALightWeightRedirectContinuation, WALightWeightRenderContinuation, and
>> WALightWeightSession. Then running the
>> 'seaside/examples/GemStone/lightweight' application you can inspect the
>> session state and see that there are only two continuations in the LRU and
>> those continuations are used over and over again. Check out the _k parameter
>> on the links and note that the parameter doesn't change. Also note that the
>> _k param for the rendering url also stays constant.
>>
>> This code is definitely in the proof of concept stage...
>>
>> The foundation of lightweight sessions is the notion that it should be
>> possible to reuse the block associated with a callback (link on a page). If
>> you can guarantee that the block doesn't reference any external state except
>> that which is provided by the _arguments_ to the block, then you can reuse
>> the WAActionCallback for whom the block and its arguments are 'identical' (I
>> used the name #receiver in this prototype, but I should have called it #arg
>> instead).
>>
>> In GemStone/S, the class SimpleBlock has just the guarantees I'm talking
>> about. I was able to implement the method BlockContext>>isSimple in Squeak,
>> that also tests for these guarantees.
>>     
>
> Wouldn't using a MessageSend offer the same advantages and be way simpler?
>
>   
>> Reusable callbacks aren't very interesting by themselves - we really need to
>> be able to reuse the contexts. In order to reuse a context we can't having
>> the component state changing over time ... if the component state isn't
>> changed, then the context can be reused (this goes for both the redirect and
>> rendering contexts).
>>     
>
> But components often have state that changes. Even simple things like
> which menu item is active or by which column a table is sorted.
>
>   
>> In the prototype, I created WALightWeightComponent to ensure that states
>> were always empty. WALightWeightTally uses a class variable for storing
>> the'tally' - by design the value is shared across all sessions....
>>     
>
> This doesn't look very useful.
>
>   
>> The rest of the classes (I subclassed in most cases) were needed to allow me
>> to implement the reuse of the callbacks and the continuations.
>>
>> If you play with this prototype, you will see that within a single session,
>> you can click the link all day long as fast as you can, and you will not be
>> accumulating session state at all. For a Squeak-based web site, I assume
>> that reducing the object load for sessions can be very important. I haven't
>> taken detailed notes, but I think that several hundred objects were being
>> created and stored with the session per page hit. With lightweight sessions,
>> there are nearly 0 objects being created and stored with the session. The
>> implication is that session expiry's can be bumped up for sites that can
>> take advantage of lightweight sessions.
>>
>> For a GemStone-based web site, this prototype brings us really close to
>> being able to sever up pages without needing to commit at all. I have a
>> little more work to go to completely eliminate commits (some of the method
>> overrides in this prototype were aimed at avoiding commits).
>>
>> I haven't worked through all of the issues, but I think that something along
>> these lines would be very useful in Seaside2.9. I can imagine that home
>> pages could use lightweight components that are shared across all sessions,
>> meaning that sessions only have to be created when a user has logged in or
>> entered a portion of the site where normal components need to be used....
>>
>> I'm really curious what you guys think.... In the mean time I will
>> attempting to apply the 'lightweight' concept to the Store example...
>>     
>
> Well, I think having a more awkward API that gives you more
> performance when you need it in general is a good thing (tm). But it
> must be worth it. Which means performance should be an order of
> magnitude greater and Seaside should really be the bottleneck.
>
> Cheers
> Philippe
>