[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