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 <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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
