[Seaside-dev] Comet request handling / Ajax performance
Andreas Raab
andreas.raab at gmx.de
Thu Aug 12 03:55:36 UTC 2010
Yes, you're absolutely right! Wow, this is pretty amazing. I never
noticed this because I'm alwaysing WebServer (which implies persistent
http connections) and consequently I would only see that problem when
running benchmarks to compare WebServer to Comanche etc. :-)
It *is* weird though; the Chrome behavior just as much as FF. But
anyway, thanks for pointing out this issue; this has some very positive
implications for the alternative approaches (I like having options :-)
Thanks,
- Andreas
On 8/5/2010 4:21 AM, Gerhard Obermann wrote:
> 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
> <mailto: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
> <mailto: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>
> <mailto: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>
> <mailto: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
> <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
> <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
> <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
More information about the seaside-dev
mailing list