[Seaside-dev] Comet request handling / Ajax performance

Thu Aug 5 11:21:16 UTC 2010

Yes i think that could be the problem, i always use 127.0.0.1 to avoid such
issues!

I am using Windows 7, Pharo 1.0, Seaside 3.0 (most recent versions are
loaded) WAKom and firefox 3.6.8!

Gerhard

On Thu, Aug 5, 2010 at 10:30 AM, Nick Ager <nick.ager at gmail.com> wrote:

> 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
>>
>
>
> _______________________________________________
> 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/b765cf4b/attachment.htm