I tried the AjaxBench with Seaside 3.0RC without any modifications and I get approx. 46 req/sec.<br>I dont't see the drop to 1 req/sec<br><br>Gerhard<br><br><div class="gmail_quote">On Wed, Aug 4, 2010 at 6:21 AM, Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi -<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Cheers,<br><font color="#888888">
- Andreas<br>
</font><br>_______________________________________________<br>
seaside-dev mailing list<br>
<a href="mailto:seaside-dev@lists.squeakfoundation.org">seaside-dev@lists.squeakfoundation.org</a><br>
<a href="http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev" target="_blank">http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev</a><br>
<br></blockquote></div><br>