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 <[email protected]> wrote: > P.S. In the end the bottle neck is ALWAYS database access. > > On Aug 24, 12:20 am, mdipierro <[email protected]> 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 <[email protected]> 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
