[Seaside-dev] Comet request handling / Ajax performance

[Gerhard Obermann]

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

Gerhard

On Wed, Aug 4, 2010 at 6:21 AM, Andreas Raab <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
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20100805/d4bc2e20/attachment.htm