I can reproduce the problem. I did on localhost with two different browsers. Using firebug I can see it takes 25seconds to download base.css (the problem is not always with the same file). While I did the test, I also monitored httpserver.log and I find that it NEVER takes more than 1.2ms serve base.css. This is what the log shows:
.... 127.0.0.1, 2010-07-22 10:16:38, GET, /michealellistest/static/images/ header.png, HTTP/1.1, 304, 0.000563 127.0.0.1, 2010-07-22 10:16:38, GET, /favicon.ico, HTTP/1.1, 400, 0.000631 127.0.0.1, 2010-07-22 10:16:55, GET, /michealellistest/static/ base.css, HTTP/1.1, 304, 0.000791 #### locks firefox for 25secs .... 127.0.0.1, 2010-07-22 10:22:42, GET, /michealellistest/static/ jquery.timers-1.2.js, HTTP/1.1, 304, 0.000552 127.0.0.1, 2010-07-22 10:22:42, GET, /favicon.ico, HTTP/1.1, 400, 0.000497 127.0.0.1, 2010-07-22 10:23:02, GET, /michealellistest/static/ superfish.js, HTTP/1.1, 304, 0.000914 #### locks chrome for 25secs Do you see the time gaps? There is a clear pattern. Under heavy load a request that results in a HTTP 400 error locks Rocket. Notice that the logging is done by a wsgi application that calls web2py wsgibase, i.e it time how long it takes web2py to receive the request and send the response. The extra time must be spent inside the web server. It is also important that the times showed in the logs are the actual time when the data is being written in the logs. You can see firefox waiting for base.css, the server waiting to log base.css and nothing else is being printed during the wait, signifying that web2py is not running any request. We need Tim! This is a problem. Massimo On Jul 22, 9:22 am, Michael Ellis <[email protected]> wrote: > I've isolated the problem but absolutely do not understand it. I can > reproduce it with a two-line change to web2py_ajax.html. Will someone with > the time and equipment please attempt to replicate this as a sanity check? > > Here's how: > > In the welcome app's web2py_ajax.html, insert the following after line 3. > response.files.insert(3,URL(r=request,c='static',f='jquery.sparkline.js')) > response.files.insert(4,URL(r=request,c='static',f='jquery.timers-1.2.js')) > > Copy the attached js files into welcome/static. They should be the same as > the versions available online. > > To reproduce the problem, serve web2py on your LAN. Open the welcome home > page on two different machines. One of them can be on the server. Briskly > reload the page 10 or more times on either machine then try to reload on the > other. In my setup, the delay is reliably 25 seconds from the time I make > the last click on the first machine. > > I'm able to reproduce this in FF, Chrome, and Safari using the latest web2py > from trunk. Haven't tried any other browsers yet. As noted previously both > machines are MacBooks running Snow Leopard. > > Mike > > jquery.timers-1.2.js > 4KViewDownload > > jquery.sparkline.js > 62KViewDownload
