[Seaside-dev] Comet request handling / Ajax performance

[Andreas Raab]

On 8/5/2010 12:27 AM, Gerhard Obermann wrote:
> I tried the AjaxBench with Seaside 3.0RC without any modifications and I
> get approx. 46 req/sec.
> I dont't see the drop to 1 req/sec

Interesting. What browser/platform/adaptor were you using? With the 
standard Seaside 3 WAComancheAdaptor I see FF 3.6 on Windows dropping to 
1 req/sec; Chrome 5 / Windows appears to run at 6-7 req/sec but in very 
strange bursts. IE8 doesn't display anything. That's all the browsers I 
have right now :-)

Cheers,
   - Andreas

> On Wed, Aug 4, 2010 at 6:21 AM, Andreas Raab <andreas.raab at gmx.de
> <mailto:andreas.raab at gmx.de>> wrote:
>
>     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
>
>     _______________________________________________
>     seaside-dev mailing list
>     seaside-dev at lists.squeakfoundation.org
>     <mailto:seaside-dev at lists.squeakfoundation.org>
>     http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
>
>
>
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev