Yes that could be really a small problem with Rocket's threaded implementation, not the GIL, which usually shows up on higher concurrency loads. Anyway that would be a point for Guido... :D
ciao, mic 2010/7/23 mdipierro <mdipie...@cs.depaul.edu> > I am not convinced this is a GIL problem. Why the lock after the 400 > errors only? > > On Jul 23, 9:18 am, Michele Comitini <michele.comit...@gmail.com> > wrote: > > Because of the GIL threads on CPython are problematic more than one could > > think. Googling "GIL python" gives an idea... > > Not to start the war threading vs forking model in general, but the GIL > will > > not go away from van Rossum's > > python implementation (no not even in 3.x), he rather suggests to stay > out > > of threading (and he means that in general). > > > > This is better clarified in this Guido's mail: > > > > http://mail.python.org/pipermail/python-3000/2007-May/007414.html > > > > ciao, > > mic > > > > 2010/7/22 Timbo <tfarr...@owassobible.org> > > > > > OK, so it's a thread-starvation issue. Let this be the interim fix > > > for web2py. I've got several busy days ahead of me so I'll put out a > > > real fix for Rocket in the coming days. > > > > > -tim > > > > > On Jul 22, 11:39 am, Michael Ellis <michael.f.el...@gmail.com> wrote: > > > > Much improved with suggested change. Latencies for .js/.css files > > > reduced > > > > to 100-150 msec. Thanks Tim! > > > > > > Cheers, > > > > Mike > > > > > > On Thu, Jul 22, 2010 at 12:27 PM, Timbo <tfarr...@owassobible.org> > > > wrote: > > > > > Try one quick change for me please...rocket is constructed around > line > > > > > 655 in main.py > > > > > > > Add a parameter to the constructor call(s): max_threads=0 > > > > > > > Please let me know if that affects the problem. > > > > > > > -tim > > > > > > > On Jul 22, 10:34 am, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > > > > 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 <michael.f.el...@gmail.com> > 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 >
