[Lift] Re: Comet Actors - single browser, multiple tabs, same URL - out of control GET problem
On Thu, Sep 17, 2009 at 9:04 AM, Dano wrote: > > David, > > I am not sure this is a matter of optimization. As you indicate in > your response, when this situation occurs "Lift will immediately end > the long polling operation in order not to starve the connections.". > This tells me the request is not being serviced properly and it > therefore is a functional issue. > > You may call it 'not a bug', but it is a limitation for > innovationgames.com as we cannot support facilitators working multiple > games at the same time (in the same browser). > Why not? (A little background for the rest of the readers, I spent 22+ months on Innovation Games. I've tested, benchmarked, and sized the application) Let's do some math. If you have 100 simultaneous games (the max for the given hardware). Each game has a facilitator that has two tabs open to two games (this is the worst case because the browser is only going to make a request once every 100 ms). So, you've got 50 browsers making 10 requests per second. That's 500 requests per second, but they are handled by a very fast path in Lift (so there's very little CPU involved) and they are all HTTP keep-alived so there's no TCP setup costs. This is on top of the 250 or so actual long poll requests that will be serviced on any given second based on modeled game play. On hardware with substantially less CPU power than the hardware that IGO is currently running on, I've benchmarked the application at > 800 requests per second with a load average of 0.24. So, even if the ping-ponged requests were consuming a lot of CPU, the total number of requests per second is well below what the existing hardware can handle. Now, as I've said, there already exists code in Lift (and was accessed in IGO until I removed it for reasons I won't go into on the public list, but having nothing to do with the functionality of the code) that allows you to that allows the Comet requests to be made against a DNS wildcarded server and allows number of simultaneous requests before the comet polling is terminated to be increased. See LiftRules.maxConcurrentRequests and LiftRules.cometServer There also exists in Lift the ability to totally change the JavaScript that's generated for long polling (see LiftRules.renderCometScript). So, to sum up: - This is a manufactured, not actual, problem for this particular user - The requested change in Lift long-polling behavior exists in the user's code and they can enable it at will - If someone needs something that's not already addressed by the LiftRules.cometServer feature, they can change how the long polling requests are made on the Lift server by creating their own long polling script. > > > Dan > > On Sep 17, 8:52 am, David Pollak > wrote: > > On Wed, Sep 16, 2009 at 10:35 PM, DFectuoso > wrote: > > > > > That seems like a logical reason why this is like this, but if i open > > > 2 tabs ofhttp://demo.liftweb.net/, both tabs start to send ajax > > > request every 100ms, that is 20 ajax request per second, 72k per hour, > > > so if an app had 100 crazy users who happen to open 2 tabs of the app > > > (this happens to me a lot, im messy with my tabs) that means 7.2 > > > million request per hour to the server? isnt that something we might > > > want to avoid somehow? > > > > Why? What's the actual cost? Have you actually measured it? Have you > > evaluated how many requests per second an HTTP connection with keep-alive > > can handle with Lift's comet code path? > > > > Please don't do premature optimization. Please worry about real > problems. > > > > > > > > > > > > > > > > > I'm guessing we can't really fight the connection limit, but we should > > > be able to specify a frequency to the js if we are going to enter to a > > > "polling" policy (instead of long poll)? > > > > > On Sep 16, 4:49 pm, David Pollak > > > wrote: > > > > On Wed, Sep 16, 2009 at 4:18 PM, Dano > wrote: > > > > > > > We have a lift app (innovationgames.com) which has a page > (actually > > > > > several) with comet actors. When we go to the same URL in two tabs > in > > > > > the same browser, we see that the long polls (GET requests) return > > > > > immediately in rapid fire succession and this behavior continues > until > > > > > we exit one of the tabs. > > > > > > > We thought maybe we did something wrong in our code, so we tried > the > > > > > same thing using demo.liftweb.net. We saw the same behavior in > the > > > > > demo site that we see in our site. > > > > > > > If you try this with something else like Gmail, it does not show > this > > > > > behavior. > > > > > > It's not a bug. > > > > > > There is a 2 connection per server per browser limit (in most > browsers > > > > although Chrome and FF 3.5 apparently have relaxed this limit). If > there > > > is > > > > a long polling operation in progress and a second request comes into > the > > > > same session, Lift will immediately end the long polling operation in > > > order
[Lift] Re: Comet Actors - single browser, multiple tabs, same URL - out of control GET problem
It is still unclear to me if the scenario I outlined above is supported by Lift or not. Can users of a site built with Lift (and comet actors) point their browser to the site in more than one tab? If so, is it reasonable for the web browser in this case to be sending multiple GET requests per second? Even with small numbers of users working this way, the number of requests sent to the server seems excessive. Dan On Sep 17, 9:26 am, David Pollak wrote: > On Wed, Sep 16, 2009 at 10:53 PM, Xavi Ramirez wrote: > > > I vaguely remember reading a thread that claimed Lift would > > auto-increase the 2 connection limit for sessions using more modern > > browsers. Is this feature in M5? > > No. It's on my to-do list. > > > > > Random Idea: > > Would it be possible to get around the 2 connection limit by sending > > each comet request to a unique sub-domain? > > That code is already in Lift. Lift supports sending comet long poll > requests to DNS wildcarded subdomains and the relaxation of the 2 connection > limit in such cases. > > However, such a setup requires non-trivial operation discipline in terms of > setting up the dns correctly, changing dns when machines are moved, setting > up properties files for given machine and run modes, etc. You're welcome to > add a wiki task for me to document the feature. > > > > > > > > > For example, current lift webapps send comet requests to: > >http://www.[your-domain].com/comet_request/96624280773/vhbz24xby3vm > > > Could lift instead send comet requests to > > comet[uniqueId].[your-domain].com/[params]? > > > Thanks, > > Xavi > > > On Wed, Sep 16, 2009 at 7:49 PM, David Pollak > > wrote: > > > > On Wed, Sep 16, 2009 at 4:18 PM, Dano wrote: > > > >> We have a lift app (innovationgames.com) which has a page (actually > > >> several) with comet actors. When we go to the same URL in two tabs in > > >> the same browser, we see that the long polls (GET requests) return > > >> immediately in rapid fire succession and this behavior continues until > > >> we exit one of the tabs. > > > >> We thought maybe we did something wrong in our code, so we tried the > > >> same thing using demo.liftweb.net. We saw the same behavior in the > > >> demo site that we see in our site. > > > >> If you try this with something else like Gmail, it does not show this > > >> behavior. > > > > It's not a bug. > > > There is a 2 connection per server per browser limit (in most browsers > > > although Chrome and FF 3.5 apparently have relaxed this limit). If there > > is > > > a long polling operation in progress and a second request comes into the > > > same session, Lift will immediately end the long polling operation in > > order > > > not to starve the connections. > > > >> I thought I would post to this group and get some feedback before > > >> submitting a bug. > > > >> Thanks in advance. > > > >> Dano > > > > -- > > > Lift, the simply functional web frameworkhttp://liftweb.net > > > Beginning Scalahttp://www.apress.com/book/view/1430219890 > > > Follow me:http://twitter.com/dpp > > > Git some:http://github.com/dpp > > -- > Lift, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > Follow me:http://twitter.com/dpp > Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Comet Actors - single browser, multiple tabs, same URL - out of control GET problem
On Wed, Sep 16, 2009 at 10:53 PM, Xavi Ramirez wrote: > > I vaguely remember reading a thread that claimed Lift would > auto-increase the 2 connection limit for sessions using more modern > browsers. Is this feature in M5? > No. It's on my to-do list. > > Random Idea: > Would it be possible to get around the 2 connection limit by sending > each comet request to a unique sub-domain? > That code is already in Lift. Lift supports sending comet long poll requests to DNS wildcarded subdomains and the relaxation of the 2 connection limit in such cases. However, such a setup requires non-trivial operation discipline in terms of setting up the dns correctly, changing dns when machines are moved, setting up properties files for given machine and run modes, etc. You're welcome to add a wiki task for me to document the feature. > > For example, current lift webapps send comet requests to: > http://www.[your-domain].com/comet_request/96624280773/vhbz24xby3vm > > Could lift instead send comet requests to > comet[uniqueId].[your-domain].com/[params]? > > Thanks, > Xavi > > On Wed, Sep 16, 2009 at 7:49 PM, David Pollak > wrote: > > > > > > On Wed, Sep 16, 2009 at 4:18 PM, Dano wrote: > >> > >> We have a lift app (innovationgames.com) which has a page (actually > >> several) with comet actors. When we go to the same URL in two tabs in > >> the same browser, we see that the long polls (GET requests) return > >> immediately in rapid fire succession and this behavior continues until > >> we exit one of the tabs. > >> > >> We thought maybe we did something wrong in our code, so we tried the > >> same thing using demo.liftweb.net. We saw the same behavior in the > >> demo site that we see in our site. > >> > >> If you try this with something else like Gmail, it does not show this > >> behavior. > > > > It's not a bug. > > There is a 2 connection per server per browser limit (in most browsers > > although Chrome and FF 3.5 apparently have relaxed this limit). If there > is > > a long polling operation in progress and a second request comes into the > > same session, Lift will immediately end the long polling operation in > order > > not to starve the connections. > >> > >> I thought I would post to this group and get some feedback before > >> submitting a bug. > > > > > >> > >> Thanks in advance. > >> > >> > >> Dano > >> > > > > > > > > -- > > Lift, the simply functional web framework http://liftweb.net > > Beginning Scala http://www.apress.com/book/view/1430219890 > > Follow me: http://twitter.com/dpp > > Git some: http://github.com/dpp > > > > > > > > > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Comet Actors - single browser, multiple tabs, same URL - out of control GET problem
David, I am not sure this is a matter of optimization. As you indicate in your response, when this situation occurs "Lift will immediately end the long polling operation in order not to starve the connections.". This tells me the request is not being serviced properly and it therefore is a functional issue. You may call it 'not a bug', but it is a limitation for innovationgames.com as we cannot support facilitators working multiple games at the same time (in the same browser). Dan On Sep 17, 8:52 am, David Pollak wrote: > On Wed, Sep 16, 2009 at 10:35 PM, DFectuoso wrote: > > > That seems like a logical reason why this is like this, but if i open > > 2 tabs ofhttp://demo.liftweb.net/, both tabs start to send ajax > > request every 100ms, that is 20 ajax request per second, 72k per hour, > > so if an app had 100 crazy users who happen to open 2 tabs of the app > > (this happens to me a lot, im messy with my tabs) that means 7.2 > > million request per hour to the server? isnt that something we might > > want to avoid somehow? > > Why? What's the actual cost? Have you actually measured it? Have you > evaluated how many requests per second an HTTP connection with keep-alive > can handle with Lift's comet code path? > > Please don't do premature optimization. Please worry about real problems. > > > > > > > > > I'm guessing we can't really fight the connection limit, but we should > > be able to specify a frequency to the js if we are going to enter to a > > "polling" policy (instead of long poll)? > > > On Sep 16, 4:49 pm, David Pollak > > wrote: > > > On Wed, Sep 16, 2009 at 4:18 PM, Dano wrote: > > > > > We have a lift app (innovationgames.com) which has a page (actually > > > > several) with comet actors. When we go to the same URL in two tabs in > > > > the same browser, we see that the long polls (GET requests) return > > > > immediately in rapid fire succession and this behavior continues until > > > > we exit one of the tabs. > > > > > We thought maybe we did something wrong in our code, so we tried the > > > > same thing using demo.liftweb.net. We saw the same behavior in the > > > > demo site that we see in our site. > > > > > If you try this with something else like Gmail, it does not show this > > > > behavior. > > > > It's not a bug. > > > > There is a 2 connection per server per browser limit (in most browsers > > > although Chrome and FF 3.5 apparently have relaxed this limit). If there > > is > > > a long polling operation in progress and a second request comes into the > > > same session, Lift will immediately end the long polling operation in > > order > > > not to starve the connections. > > > > > I thought I would post to this group and get some feedback before > > > > submitting a bug. > > > > > Thanks in advance. > > > > > Dano > > > > -- > > > Lift, the simply functional web frameworkhttp://liftweb.net > > > Beginning Scalahttp://www.apress.com/book/view/1430219890 > > > Follow me:http://twitter.com/dpp > > > Git some:http://github.com/dpp > > -- > Lift, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > Follow me:http://twitter.com/dpp > Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Comet Actors - single browser, multiple tabs, same URL - out of control GET problem
On Wed, Sep 16, 2009 at 10:35 PM, DFectuoso wrote: > > That seems like a logical reason why this is like this, but if i open > 2 tabs of http://demo.liftweb.net/, both tabs start to send ajax > request every 100ms, that is 20 ajax request per second, 72k per hour, > so if an app had 100 crazy users who happen to open 2 tabs of the app > (this happens to me a lot, im messy with my tabs) that means 7.2 > million request per hour to the server? isnt that something we might > want to avoid somehow? > Why? What's the actual cost? Have you actually measured it? Have you evaluated how many requests per second an HTTP connection with keep-alive can handle with Lift's comet code path? Please don't do premature optimization. Please worry about real problems. > > I'm guessing we can't really fight the connection limit, but we should > be able to specify a frequency to the js if we are going to enter to a > "polling" policy (instead of long poll)? > > On Sep 16, 4:49 pm, David Pollak > wrote: > > On Wed, Sep 16, 2009 at 4:18 PM, Dano wrote: > > > > > We have a lift app (innovationgames.com) which has a page (actually > > > several) with comet actors. When we go to the same URL in two tabs in > > > the same browser, we see that the long polls (GET requests) return > > > immediately in rapid fire succession and this behavior continues until > > > we exit one of the tabs. > > > > > We thought maybe we did something wrong in our code, so we tried the > > > same thing using demo.liftweb.net. We saw the same behavior in the > > > demo site that we see in our site. > > > > > If you try this with something else like Gmail, it does not show this > > > behavior. > > > > It's not a bug. > > > > There is a 2 connection per server per browser limit (in most browsers > > although Chrome and FF 3.5 apparently have relaxed this limit). If there > is > > a long polling operation in progress and a second request comes into the > > same session, Lift will immediately end the long polling operation in > order > > not to starve the connections. > > > > > I thought I would post to this group and get some feedback before > > > submitting a bug. > > > > > Thanks in advance. > > > > > Dano > > > > -- > > Lift, the simply functional web frameworkhttp://liftweb.net > > Beginning Scalahttp://www.apress.com/book/view/1430219890 > > Follow me:http://twitter.com/dpp > > Git some:http://github.com/dpp > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Comet Actors - single browser, multiple tabs, same URL - out of control GET problem
I vaguely remember reading a thread that claimed Lift would auto-increase the 2 connection limit for sessions using more modern browsers. Is this feature in M5? Random Idea: Would it be possible to get around the 2 connection limit by sending each comet request to a unique sub-domain? For example, current lift webapps send comet requests to: http://www.[your-domain].com/comet_request/96624280773/vhbz24xby3vm Could lift instead send comet requests to comet[uniqueId].[your-domain].com/[params]? Thanks, Xavi On Wed, Sep 16, 2009 at 7:49 PM, David Pollak wrote: > > > On Wed, Sep 16, 2009 at 4:18 PM, Dano wrote: >> >> We have a lift app (innovationgames.com) which has a page (actually >> several) with comet actors. When we go to the same URL in two tabs in >> the same browser, we see that the long polls (GET requests) return >> immediately in rapid fire succession and this behavior continues until >> we exit one of the tabs. >> >> We thought maybe we did something wrong in our code, so we tried the >> same thing using demo.liftweb.net. We saw the same behavior in the >> demo site that we see in our site. >> >> If you try this with something else like Gmail, it does not show this >> behavior. > > It's not a bug. > There is a 2 connection per server per browser limit (in most browsers > although Chrome and FF 3.5 apparently have relaxed this limit). If there is > a long polling operation in progress and a second request comes into the > same session, Lift will immediately end the long polling operation in order > not to starve the connections. >> >> I thought I would post to this group and get some feedback before >> submitting a bug. > > >> >> Thanks in advance. >> >> >> Dano >> > > > > -- > Lift, the simply functional web framework http://liftweb.net > Beginning Scala http://www.apress.com/book/view/1430219890 > Follow me: http://twitter.com/dpp > Git some: http://github.com/dpp > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Comet Actors - single browser, multiple tabs, same URL - out of control GET problem
That seems like a logical reason why this is like this, but if i open 2 tabs of http://demo.liftweb.net/, both tabs start to send ajax request every 100ms, that is 20 ajax request per second, 72k per hour, so if an app had 100 crazy users who happen to open 2 tabs of the app (this happens to me a lot, im messy with my tabs) that means 7.2 million request per hour to the server? isnt that something we might want to avoid somehow? I'm guessing we can't really fight the connection limit, but we should be able to specify a frequency to the js if we are going to enter to a "polling" policy (instead of long poll)? On Sep 16, 4:49 pm, David Pollak wrote: > On Wed, Sep 16, 2009 at 4:18 PM, Dano wrote: > > > We have a lift app (innovationgames.com) which has a page (actually > > several) with comet actors. When we go to the same URL in two tabs in > > the same browser, we see that the long polls (GET requests) return > > immediately in rapid fire succession and this behavior continues until > > we exit one of the tabs. > > > We thought maybe we did something wrong in our code, so we tried the > > same thing using demo.liftweb.net. We saw the same behavior in the > > demo site that we see in our site. > > > If you try this with something else like Gmail, it does not show this > > behavior. > > It's not a bug. > > There is a 2 connection per server per browser limit (in most browsers > although Chrome and FF 3.5 apparently have relaxed this limit). If there is > a long polling operation in progress and a second request comes into the > same session, Lift will immediately end the long polling operation in order > not to starve the connections. > > > I thought I would post to this group and get some feedback before > > submitting a bug. > > > Thanks in advance. > > > Dano > > -- > Lift, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > Follow me:http://twitter.com/dpp > Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Comet Actors - single browser, multiple tabs, same URL - out of control GET problem
On Wed, Sep 16, 2009 at 4:18 PM, Dano wrote: > > We have a lift app (innovationgames.com) which has a page (actually > several) with comet actors. When we go to the same URL in two tabs in > the same browser, we see that the long polls (GET requests) return > immediately in rapid fire succession and this behavior continues until > we exit one of the tabs. > > We thought maybe we did something wrong in our code, so we tried the > same thing using demo.liftweb.net. We saw the same behavior in the > demo site that we see in our site. > > If you try this with something else like Gmail, it does not show this > behavior. > It's not a bug. There is a 2 connection per server per browser limit (in most browsers although Chrome and FF 3.5 apparently have relaxed this limit). If there is a long polling operation in progress and a second request comes into the same session, Lift will immediately end the long polling operation in order not to starve the connections. > I thought I would post to this group and get some feedback before > submitting a bug. > > > Thanks in advance. > > > Dano > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
