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 >
