On Wed, Oct 3, 2012 at 11:31 AM, Niphlod <niph...@gmail.com> wrote: > me too. The default webserver is not - usually - meant for production > anyway. I started the test with the idea "let's see if tornado on windows > (i.e. without all the goodies of select/epoll) can be at least comparable > with a threaded server". > > PS: cherrypy (and rocket) uses a separate thread for every request. If I got > that part right, limiting the threadpool to max 1 means that no concurrency > at all is achieved. Unfortunately, it seems that I missed a step. Limiting > using > > server = wsgiserver.CherryPyWSGIServer(address, app, numthreads=1, max=1) > > seems to raise rps to 68.93. 99% of the requests are served in 3078 ms. > > server = wsgiserver.CherryPyWSGIServer(address, app, numthreads=10, max=20) > > stops to rps 14.95 while the 99% of the requests are served in 8034 ms. > > If someone can explain this to me I'll be glad to offer him a beer if he > passes nearby Milan. >
Think about a bar with 10 barmans and two beer faucets (I have to search to know I to call - http://www.homebrewery.com/images/chrome-beer-faucet.jpg) At some time the barmans start to starving each other to handle all the beer requests. I guess it's the thread context switch penalty plus GIL. Try cherrypy with: numthreads=2, max=2 You should get about the same performance of single thread or better. A good reading that can give you some enlightenment: http://www.slideshare.net/cjgiridhar/pycon11-python-threads-dive-into-gil-9315128 www.dabeaz.com/python/GIL.pdf http://en.wikipedia.org/wiki/Context_switch Ricardo --
