On Thu, Sep 17, 2009 at 9:04 AM, Dano <olearydani...@gmail.com> 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 <feeder.of.the.be...@gmail.com> > wrote: > > On Wed, Sep 16, 2009 at 10:35 PM, DFectuoso <santiago1...@gmail.com> > 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 <feeder.of.the.be...@gmail.com> > > > wrote: > > > > On Wed, Sep 16, 2009 at 4:18 PM, Dano <olearydani...@gmail.com> > 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 > > > -- 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 -~----------~----~----~----~------~----~------~--~---
