Python WSGI server - CherryPy 3.0

Today I noticed that CherryPy 3.0 has been released.

CherryPy is a multi-threaded production web server written in python.

The part I am interested in is the Web Server Gateway Interface(WSGI) component. WSGI is the glue which allows lots of python web code to talk to each other. A python WSGI server allows you to run python applications.

Up until now I have mostly been using the twisted.web2 wsgi code. This is fairly nice, and I can use other parts of twisted with it. However twisted.web2 is not finished.

CherryPy on the other hand has had a lot of work done on it polishing it up. It is used by quite a lot of people on real websites. A nice part of this work is the optimization work that has been done on it. Apparently CherryPy 3.0 is three times faster than the previous 2.x release. One of the authors also claims that it is the fastest WSGI server around.

For my simple benchmarks on my application it goes from 38 req/second with twisted, to 54 req/second with a slow AMD Duron 850mhz linux computer. So not amazingly faster, but still a worthwhile speedup.

The WSGI server in CherryPy comes as a stand alone module. So you can just download one .py file and use it. Pretty easy. CherryPy comes with lots of other goodies, but I'm not interested in those. Maybe I'll play with them later, but for now I just want a python WSGI server.

The single file WSGI server is less than 1000 lines of code, many of which are comments and documentation. So it's pretty simple to read, debug, and modify.

It took me about 20 minutes to convert my application to use the cherrypy WSGI server instead of twisted. It was much easier to figure out, and well documented compared to twisted.

One problem I have is that of memory consumption. The cherrypy server seems to use more memory than the twisted one. I managed to reduce it to 25MB using one thread. The default of 10 threads uses up 96MB. It would be great if the server could be enhanced for low memory usage. So when there's not much traffic it could use 1 thread, and when there is a lot of traffic increase the number of worker threads. Much like how apache has settings for how many threads or processes are used.

Another difference between the twisted.web2 WSGI server, and the cherrypy one is that the cherrypy one prints tracebacks to the browser. Which is fine for development, but is not something you'd want for production.

One problem I had was stopping the server. Using ctrl+C gives a traceback and makes it non responsive. Meaning I have to kill it another way. This is kind of annoying, and slows my development a little. Since I need to restart the server often some times.

At this stage, because of the less memory usage, and how it does not display errors to the user, and the ctrl+c problem I have - I think I will stay with the twisted WSGI server. However I am keeping an eye on the cherrypy server because of its better performance.





Melbourne Web Developer Written by a Melbourne web developer. Available for your projects - python, php, mysql, e commerce, javascript, CMS, css, flash, actionscript, games, postgresql, xml.

Comments

fumanchu said…
> At this stage, because of the less memory usage,
> and how it does not display errors to the user,
> and the ctrl+c problem I have - I think I
> will stay with the twisted WSGI server.

Then you might want some of the "extra goodies" CherryPy offers. :) The request object and _cpwsgi module do error trapping (but only for CP apps), and the server and engine objects do process control (like interrupt and signal handling). Hopefully, you'll find them as easy to pick up.
If performance is the biggest practical issue you have with Twisted's WSGI server, you might be glad to hear that it is written in a grossly inefficient manner and no one has tried to optimize it yet. :) It would be foolish for me to speculate on what speedup is actually achievable without providing supporting evidence, but a significant improvement without a huge amount of work does seem likely to me. Feel like contributing something? I'm sure someone familiar with the code and issues involved would be happy to give out any pointers you might need.
Seun Osewa said…
If you're running CherryPy behind a reverse proxy, you don't need more than 2-4 threads. That should cut your memory usage significantly.
Anonymous said…
I currently have the same memory consumption problem, but seems I can't find where to configure the number of threads cherrypy uses, could anyone help me with that, please?

Popular posts from this blog

Draft 3 of, ^Let's write a unit test!^

Is PostgreSQL good enough?

post modern C tooling - draft 6