[Seaside-dev] Comet request handling / Ajax performance

[Andreas Raab]

Hi Julian -

Okay, I take it that as an "yes we do care" :-) and as a consequence 
I've filed http://code.google.com/p/seaside/issues/detail?id=591 with a 
rather more complete implementation of yesterday's proof of concept.

If you install the three change sets provided above, you can use 
WAComancheAdaptor for both streamed and buffered responses. The Comet 
examples work out of the box and you can always stream responses by just 
inserting a #flush in your rendering context.

 From WAComboResponse's class comment:
--------------------------------------
WAComboResponse is a combination of a buffered and a streaming response. 
By default, WAComboResponse will buffer the entire response to be sent 
at the end of the request processing cycle. If streaming is desired, the 
response can be flushed by sending it the #flush message. Flushing a 
response will sent all previously buffered data using chunked 
transfer-encoding (which preserves persistent connections). Clients can 
flush the response as often as they want at appropriate points in their 
response generation; everything buffered up to that point will be sent. 
For example, a search results page might use something like:

renderContentOn: aCanvas
	"Render the search page"

	self renderSearchLabelOn: aCanvas.
	aCanvas flush. "flush before starting search to give immediate feedback"

	self searchResultsDo:[:aResult|
		self renderSearchResultOn: aCanvas.
		aCanvas flush. "flush after each search result"
	].

After a response has been flushed once, header modifications are no 
longer possible and will raise a WAIllegalStateException.

Server adaptors need to be aware that a committed response must be 
closed, when complete. An uncommitted response should be handled as 
usual by the server adapter.
--------------------------------------

Obviously, the above completely subsumes the Comet issues from 
yesterday, since now Comet simply uses the streaming provided by 
WAComboResponse.

The one thing that's ugly right now is the hack to get Comanche to 
ignore committed responses. I'm not proud of it; if somebody knows 
Comanche better than me, let me know what the 'proper' way is to deal 
with this.

Cheers,
   - Andreas

On 8/4/2010 12:16 PM, Julian Fitzell wrote:
> 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
>>
>>
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>