[Seaside-dev] Comet request handling / Ajax performance

Andreas Raab andreas.raab at gmx.de
Wed Aug 4 04:21:07 UTC 2010


Hi -

I have a couple of questions about Comet request handling and related 
performance issues. Comet currently insists on having a subclass of 
WAStreamedResponse but if one looks at the code more closely it is 
pretty clear that there's a bunch of unneeded complexity here. It seems 
to me that what Comet wants is access to the stream so it can push the 
data; but since the Comet request's life cycle is such that it never 
returns to the caller, the use of WAStreamedResponse is quite simply 
overkill. The same result can be achieved by having a WAResponse return 
a suitable #cometStream (i.e., the external socket stream to write data 
to) and prevent WABufferedResponse from inserting the Content-Length 
header when pushing out the initial response.

At this point, any subclass of WAResponse that can provide a suitable 
cometStream is capable of supporting Comet. I've implemented this as a 
proof of concept in a subclass of WABufferedResponse (see attached 
CometRequests.cs) that can be used by any server adaptor that has a 
SocketStream available, such as Comanche.

You might wonder why I care about this. Simply put: Ajax response times. 
I've been trying to see if one can get interactive update rates using 
Ajax updaters and/or Comet but the design of WABufferedResponse is such 
that that it pretty much forces the server to close the connection after 
each request. Which kills all the performance for Ajax requests since 
Ajax performance pretty much exclusively relies on persistent HTTP 
connections (in my experiments the performance drops from a nice steady 
50 req/sec using a persistent HTTP connection to 1 req/sec when the 
connection is closed). I'm actually a little surprised that nobody has 
complained yet about the abysmal performance of Ajax :-) And of course 
this only gets worse when you do it over https which I eventually intend 
to do.

So, right now the alternative is that your server will EITHER support 
Comet OR efficient Ajax updates but not both. I can almost certainly 
work my way around this for WebServer but what I'm curious about is if 
people here think this should be fixed in Seaside in general or not. It 
depends a little on how you value both Comet and Ajax and how important 
wide and efficient support for either one is. I won't invest any more 
time in this for now, but there are a couple of obvious further 
simplifications given that WAStreamedResponse appears to be unused 
outside of Comet, and of course WACometResponse could be trivially 
folded into WABufferedResponse by pushing the cometStream up.

For comparison, I'm also attaching my little Ajax benchmark. If you run 
it with WAWebServerAdaptor you should see a nice steady 50 req/secs 
whereas all other adaptors drop to about 1 req/sec.

Cheers,
   - Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CometRequests.cs
Type: application/text
Size: 4484 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20100803/a7863f6e/CometRequests-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AjaxBench.cs
Type: application/text
Size: 1183 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20100803/a7863f6e/AjaxBench-0001.bin


More information about the seaside-dev mailing list