[Seaside-dev] Comet request handling / Ajax performance

[Nick Ager]

Could the discrepancy be down to the Windows 7 localhost dns issue see:
http://lists.squeakfoundation.org/pipermail/seaside/2010-March/023005.html

On 5 August 2010 08:40, Andreas Raab <andreas.raab at gmx.de> wrote:

> On 8/5/2010 12:27 AM, Gerhard Obermann wrote:
>
>> 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
>>
>
> 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 :-)
>
> Cheers,
>  - Andreas
>
>  On Wed, Aug 4, 2010 at 6:21 AM, Andreas Raab <andreas.raab at gmx.de
>> <mailto: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
>>    <mailto: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
>>
> _______________________________________________
> 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/52ad7835/attachment.htm