Comet request handling / Ajax performance
Locked
Comet request handling / Ajax performance
 
|
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 [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
CometRequests.cs (6K)
Re: Comet request handling / Ajax performance
|
|
I don't think I'm the right one to answer about Comet as I know very
little about it. WAStreamedResponse is, however, useful in any situation. You will get better-feeling response using WAStreamedResponse since the browser can begin rendering before Seaside has finished generating the whole HTML content. The tradeoff is that if you encounter an error during rendering or decide you'd actually like to do a redirect or similar, the content to this point has already gone to the browser. For the redirect or anything that needs to add or modify headers, you're hooped. For the error, you can still display a walkback but it will follow the already-sent content instead of being on its own page. Julian On Wed, Aug 4, 2010 at 5:21 AM, Andreas Raab <[hidden email]> 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 > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev > > seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: Comet request handling / Ajax performance
|
|
Hi Julian -
Okay, I take it that as an "yes we do care" :-) and as a consequence I've filed http://code.google.com/p/seaside/issues/detail?id=591 with a rather more complete implementation of yesterday's proof of concept. If you install the three change sets provided above, you can use WAComancheAdaptor for both streamed and buffered responses. The Comet examples work out of the box and you can always stream responses by just inserting a #flush in your rendering context. From WAComboResponse's class comment: -------------------------------------- WAComboResponse is a combination of a buffered and a streaming response. By default, WAComboResponse will buffer the entire response to be sent at the end of the request processing cycle. If streaming is desired, the response can be flushed by sending it the #flush message. Flushing a response will sent all previously buffered data using chunked transfer-encoding (which preserves persistent connections). Clients can flush the response as often as they want at appropriate points in their response generation; everything buffered up to that point will be sent. For example, a search results page might use something like: renderContentOn: aCanvas "Render the search page" self renderSearchLabelOn: aCanvas. aCanvas flush. "flush before starting search to give immediate feedback" self searchResultsDo:[:aResult| self renderSearchResultOn: aCanvas. aCanvas flush. "flush after each search result" ]. After a response has been flushed once, header modifications are no longer possible and will raise a WAIllegalStateException. Server adaptors need to be aware that a committed response must be closed, when complete. An uncommitted response should be handled as usual by the server adapter. -------------------------------------- Obviously, the above completely subsumes the Comet issues from yesterday, since now Comet simply uses the streaming provided by WAComboResponse. The one thing that's ugly right now is the hack to get Comanche to ignore committed responses. I'm not proud of it; if somebody knows Comanche better than me, let me know what the 'proper' way is to deal with this. Cheers, - Andreas On 8/4/2010 12:16 PM, Julian Fitzell wrote: > I don't think I'm the right one to answer about Comet as I know very > little about it. WAStreamedResponse is, however, useful in any > situation. You will get better-feeling response using > WAStreamedResponse since the browser can begin rendering before > Seaside has finished generating the whole HTML content. The tradeoff > is that if you encounter an error during rendering or decide you'd > actually like to do a redirect or similar, the content to this point > has already gone to the browser. For the redirect or anything that > needs to add or modify headers, you're hooped. For the error, you can > still display a walkback but it will follow the already-sent content > instead of being on its own page. > > Julian > > On Wed, Aug 4, 2010 at 5:21 AM, Andreas Raab<[hidden email]> 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 >> [hidden email] >> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev >> >> > _______________________________________________ > seaside-dev mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev > seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: Comet request handling / Ajax performance
|
|
In reply to this post by Andreas.Raab
On 8/3/2010 9:21 PM, Andreas Raab wrote:
> You might wonder why I care about this. Simply put: Ajax response times. And to bring this point home, I've installed a Seaside 3 image with WebServer and the changes from http://code.google.com/p/seaside/issues/detail?id=591 on http://ardemo.seasidehosting.st. The interesting parts to look at (and possibly wireshark if you're interested) are: http://ardemo.seasidehosting.st/seaside/javascript/jquery/ajaxanddommanipulation Click *quickly* on either "prepend" or "append" and you should see significantly better responses than running any other server adaptor. It's quite noticable in Firefox; with WAComancheAdaptor each update takes about a second. http://ardemo.seasidehosting.st/seaside/comet/counter Just a demo illustrating that streaming via Comet really works with using WAComboResponse. Wireshark it to see the chunked transfer-encoding. http://ardemo.seasidehosting.st/seaside/ajaxBench The ajax updater benchmark. Runs at 30 req/sec for me which is pretty good given a ping time of 180msecs to the server (any TCP retransmit will incur 180msecs penalty). Cheers, - Andreas _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: Comet request handling / Ajax performance
|
|
In reply to this post by Andreas.Raab
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 Gerhard On Wed, Aug 4, 2010 at 6:21 AM, Andreas Raab <[hidden email]> wrote: Hi - _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: Comet request handling / Ajax performance
|
|
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 <[hidden email] > <mailto:[hidden email]>> 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 > [hidden email] > <mailto:[hidden email]> > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev > > > > > _______________________________________________ > seaside-dev mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
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 <[hidden email]> wrote:
_______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: Comet request handling / Ajax performance
|
|
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 <[hidden email]> wrote: Could the discrepancy be down to the Windows 7 localhost dns issue see: http://lists.squeakfoundation.org/pipermail/seaside/2010-March/023005.html _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: Comet request handling / Ajax performance
|
|
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 <[hidden email] > <mailto:[hidden email]>> 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 <[hidden email] > <mailto:[hidden email]>> 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 > <[hidden email] <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>>> > 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 > [hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>> > > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev > > > > > _______________________________________________ > seaside-dev mailing list > [hidden email] > <mailto:[hidden email]> > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev > > _______________________________________________ > seaside-dev mailing list > [hidden email] > <mailto:[hidden email]> > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev > > > > _______________________________________________ > seaside-dev mailing list > [hidden email] > <mailto:[hidden email]> > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev > > > > > _______________________________________________ > seaside-dev mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
«
Return to Seaside Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |