Could the discrepancy be down to the Windows 7 localhost dns issue see: <a href="http://lists.squeakfoundation.org/pipermail/seaside/2010-March/023005.html">http://lists.squeakfoundation.org/pipermail/seaside/2010-March/023005.html</a> <br>
<br><div class="gmail_quote">On 5 August 2010 08:40, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 8/5/2010 12:27 AM, Gerhard Obermann wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I tried the AjaxBench with Seaside 3.0RC without any modifications and I<br>
get approx. 46 req/sec.<br>
I dont't see the drop to 1 req/sec<br>
</blockquote>
<br></div>
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 :-)<br>
<br>
Cheers,<br>
- Andreas<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Wed, Aug 4, 2010 at 6:21 AM, Andreas Raab <<a href="mailto:andreas.raab@gmx.de" target="_blank">andreas.raab@gmx.de</a><br></div><div><div></div><div class="h5">
<mailto:<a href="mailto:andreas.raab@gmx.de" target="_blank">andreas.raab@gmx.de</a>>> wrote:<br>
<br>
Hi -<br>
<br>
I have a couple of questions about Comet request handling and<br>
related performance issues. Comet currently insists on having a<br>
subclass of WAStreamedResponse but if one looks at the code more<br>
closely it is pretty clear that there's a bunch of unneeded<br>
complexity here. It seems to me that what Comet wants is access to<br>
the stream so it can push the data; but since the Comet request's<br>
life cycle is such that it never returns to the caller, the use of<br>
WAStreamedResponse is quite simply overkill. The same result can be<br>
achieved by having a WAResponse return a suitable #cometStream<br>
(i.e., the external socket stream to write data to) and prevent<br>
WABufferedResponse from inserting the Content-Length header when<br>
pushing out the initial response.<br>
<br>
At this point, any subclass of WAResponse that can provide a<br>
suitable cometStream is capable of supporting Comet. I've<br>
implemented this as a proof of concept in a subclass of<br>
WABufferedResponse (see attached CometRequests.cs) that can be used<br>
by any server adaptor that has a SocketStream available, such as<br>
Comanche.<br>
<br>
You might wonder why I care about this. Simply put: Ajax response<br>
times. I've been trying to see if one can get interactive update<br>
rates using Ajax updaters and/or Comet but the design of<br>
WABufferedResponse is such that that it pretty much forces the<br>
server to close the connection after each request. Which kills all<br>
the performance for Ajax requests since Ajax performance pretty much<br>
exclusively relies on persistent HTTP connections (in my experiments<br>
the performance drops from a nice steady 50 req/sec using a<br>
persistent HTTP connection to 1 req/sec when the connection is<br>
closed). I'm actually a little surprised that nobody has complained<br>
yet about the abysmal performance of Ajax :-) And of course this<br>
only gets worse when you do it over https which I eventually intend<br>
to do.<br>
<br>
So, right now the alternative is that your server will EITHER<br>
support Comet OR efficient Ajax updates but not both. I can almost<br>
certainly work my way around this for WebServer but what I'm curious<br>
about is if people here think this should be fixed in Seaside in<br>
general or not. It depends a little on how you value both Comet and<br>
Ajax and how important wide and efficient support for either one is.<br>
I won't invest any more time in this for now, but there are a couple<br>
of obvious further simplifications given that WAStreamedResponse<br>
appears to be unused outside of Comet, and of course WACometResponse<br>
could be trivially folded into WABufferedResponse by pushing the<br>
cometStream up.<br>
<br>
For comparison, I'm also attaching my little Ajax benchmark. If you<br>
run it with WAWebServerAdaptor you should see a nice steady 50<br>
req/secs whereas all other adaptors drop to about 1 req/sec.<br>
<br>
Cheers,<br>
- Andreas<br>
<br>
_______________________________________________<br>
seaside-dev mailing list<br>
<a href="mailto:seaside-dev@lists.squeakfoundation.org" target="_blank">seaside-dev@lists.squeakfoundation.org</a><br></div></div>
<mailto:<a href="mailto:seaside-dev@lists.squeakfoundation.org" target="_blank">seaside-dev@lists.squeakfoundation.org</a>><div class="im"><br>
<a href="http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev" target="_blank">http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev</a><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
seaside-dev mailing list<br>
<a href="mailto:seaside-dev@lists.squeakfoundation.org" target="_blank">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>
</div></blockquote><div><div></div><div class="h5">
_______________________________________________<br>
seaside-dev mailing list<br>
<a href="mailto:seaside-dev@lists.squeakfoundation.org" target="_blank">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>
</div></div></blockquote></div><br>