[Seaside] HTTP Performance

[Sven Van Caekenberghe]

On 19 Nov 2003, at 21:31, Avi Bryant wrote:

> One quick note - when you're benchmarking Seaside, you are always 
> hitting the same session, which probably isn't a realistic load.  
> Seaside serializes requests to a single session, so even though you 
> are running ab with concurrency at 4, you are not actually getting any 
> concurrency there.  If it were possible to use rotating URLs in your 
> benchmarks, you might see better results (you might not, of course).  
> I don't think ab has a mode to do this, though...

Now that I come to think of it, you're absolutely right.
ab is quite limited, it can only hit 1 static url, the way Seaside is 
dealing with URLs is too sophisticated.

> One thing that might change the apparent responsiveness is to go into 
> the configuration page for your Seaside app and set "Always Redirect" 
> to false.  This will cut the number of HTTP requests made in half.

I did set 'always redirect' to false (ab can't follow a 'moved' 
response, so instead of doing it twice, it does almost nothing, and 
gives a very high score ;-)
But the first redirect from /seaside/benchmark to 
/seaside/benchmark/@TMuBQaFlUEMQrUXU/wPipEjSq always has to happen, 
that is why I had to give that last URL to ab, otherwise it wouldn't 
work.
The side effect of that was of course the serialization on the same 
session, and an effective elimination of the concurrency (we did 
already notice that varying the -c parameter has little effect on 
seaside, now we know why)

> However, I should also say that performance simply hasn't been a 
> priority yet.  We haven't yet had a deployment of Seaside (or I 
> haven't heard about one) where the hardware we were running it on was 
> insufficient for the load it was getting, even given the poor 
> optimization of the framework.  I am sure this will happen before 
> long, and at that point I'll have to do some serious profiling and 
> speed things up.  I'll probably try to take a couple of hours tonight 
> and see if there's any low hanging fruit I can grab.  Please don't run 
> away because of these initial results - we're committed to making this 
> a viable platform for enterprise development.

We won't run away, Seaside and Squeak are too interesting !
I just wanted to make a point to provoke some discussion about this 
issue.
If we can set up a benchmark so that seaside does concurrent 
processing, the dynamic case will most probably come closer to the 
static case - but the static case will always be the upper limit.

> Like Stephen, I'm intrigued by your 50rps figure for Comanche - that's 
> the number that I always seem to come up with as well.  There *must* 
> be something throttling that, and we need to get to the bottom of it.

And that is pretty strange indeed.

Sven