John, Tnx ... I'll keep this under my pillow ;-)
2010/8/24 John Heenan <johnmhee...@gmail.com>: > Lee's 'The Problem with Threads' link is at > http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf > > There is in Lee at http://ptolemy.eecs.berkeley.edu/%7Eeal/ > > John Heenan > > On Aug 25, 5:00 am, John Heenan <johnmhee...@gmail.com> wrote: >> Can't we at least have an acknowledgement that it is not necessary for >> web2py to use a thread per request model and that web2py could instead >> use an event model? >> >> WSGI can be viewed as an evil conspiracy to force Python web apps to >> follow the Apache thread per request model! Also with Apace mod_wsgi, >> Apache controls the Python process that web2py runs under! How evil >> and ugly! >> >> There is no inherent reason why web2py needs to run a separate thread >> for each NON static http request, if WSGI is not used! >> >> If web2py uses WSGI then a thread per request is forced upon web2py. >> This suits Apache but not web serves with better event driven models >> such as Lighttpd and Nginx >> >> For example Lighttpd does not even support WSGI. Instead web2py used >> fastcgi for communication Lighttpd via a UNIX socket and web2py then >> needlessly converts each request into a thread for handling by a WSGI >> handler! >> >> Why should web2py be forced into using a thread model? Anyone who >> writes PC applications avoids thread as if they are a plague. Even >> academics openly call using threads evil. Here is an article by Edward >> A. Lee professor at Berkely University with the title "The Problem >> with Threads" (PDF). >> >> John Heenan >> >> On Aug 25, 1:00 am, John Heenan <johnmhee...@gmail.com> wrote: >> >> > There is absolutely no need to serve up static web pages of a pure >> > Python web app or a WGSI app with a separate thread. It is >> > inefficient to use an inbuilt web server (of a Python web app) or >> > Apache (if WGSI used) to serve up static web pages using separate >> > threads. Both Lighttpd and Nginx are well known web servers that >> > thrash Apache in objective tests for static pages when a web server is >> > under load. These web servers use event handlers to serve static web >> > pages, not necessarily separate threads. >> >> > Of course the question remains, how much can the performance of WSGI >> > type apps be improved by an analogous event handling model within the >> > app and how much of a change in development style would be required to >> > take full advantage of such an approach. As far as I am aware these >> > questions has never even been posed. >> >> > Further background: >> >> > There is no need to use web2py to serve up its css pages, javascript >> > and images. A compiled static language (such as C) web server can be >> > used instead. >> >> > The question then becomes which web server. The answer is obvious: web >> > servers that use event handlers to serve static web pages, not >> > necessarily threads. Unfortunately you will find religious bigots, >> > even on this forum, who will ridicule anyone who points out the >> > obvious. Expect abuse from this reply. >> >> > John Heenan >> >> > On Aug 24, 3:21 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: >> >> > > P.S. In the end the bottle neck is ALWAYS database access. >> >> > > On Aug 24, 12:20 am, mdipierro <mdipie...@cs.depaul.edu> wrote: >> >> > > > In Java a serverlet, as far as I understand, is a class which conforms >> > > > to some API that allows it to serve one http request. Each instance is >> > > > executed in its own thread. The Python equivalent of the serverlet API >> > > > is a WSGI application and web2py is based on WSGI, therefore the >> > > > parallelization mechanism is equivalent to Java serverlets. >> >> > > > In web2py (the same in Django, Pylons, any any WSGI app) each http >> > > > request is executed in its own thread. Threads are recycled to server >> > > > non-concurrent requests and reuse database connections (pooling) >> > > > without need to close and reopen them. The web server can be >> > > > configured for a min number and a max number of threads. >> >> > > > I think the GIL in this context is a false problem. In fact in >> > > > production you can use Apache and run as many processes as the number >> > > > of cores that you have. Each process will create as many threads as it >> > > > needs to server multiple requests. The GIL is a problems only if one >> > > > process runs multiple threads on multiple cores. It is possible there >> > > > are some caveats with many cores but I have not really played with >> > > > apache configurations and benchmarks. >> >> > > > I do not think using Jython helps anything. According to these tests: >> > > > http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-p... >> > > > http://pyevolve.sourceforge.net/wordpress/?p=1189 >> > > > Jython is 2x-3x slower than cpython. So you may get better scaling >> > > > with multiple cores but you pay huge perfomance hit. >> >> > > > Web2py runs on Jython but there is a known bug in Java regular >> > > > expressions that Sun marked as "won'tfix" that can cause runaway >> > > > problems when parsing complex templates. This is not a web2py specific >> > > > problem but we have seen effects of the bug in some web2py apps. >> >> > > > Massimo >> >> > > > On Aug 23, 11:29 pm, pierreth <pierre.thibau...@gmail.com> wrote: >> >> > > > > Hello, >> >> > > > > I would like to know how Web2py is managing threads. Is it like Java >> > > > > servlets where requests are mapped to servlets while one servlet >> > > > > object can be used by multiple threads at the same time to serve many >> > > > > requests? >> >> > > > > Are some users here using Jython with Web2py to get around the ugly >> > > > > Pyhton GIL? I would to know about your experience. >> >> > > > > ------------------ >> > > > > Pierre
