I agree with you. web2py does not care. It is the web server that decides. The question that started this thread was about the built-in web server and it does follow the thread model.
On Aug 24, 2:00 pm, 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