[Seaside-dev] Comet request handling / Ajax performance

[Julian Fitzell]

I don't think I'm the right one to answer about Comet as I know very
little about it. WAStreamedResponse is, however, useful in any
situation. You will get better-feeling response using
WAStreamedResponse since the browser can begin rendering before
Seaside has finished generating the whole HTML content. The tradeoff
is that if you encounter an error during rendering or decide you'd
actually like to do a redirect or similar, the content to this point
has already gone to the browser. For the redirect or anything that
needs to add or modify headers, you're hooped. For the error, you can
still display a walkback but it will follow the already-sent content
instead of being on its own page.

Julian

On Wed, Aug 4, 2010 at 5: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
>
>