CherryPy try-out

I’ve been trying out CherryPy for a hobby website I’m developing. I got annoyed by Quixote and thought I might want to try CherryPy. CherryPy is a web development framework. Basically, it makes it easy to create dynamic webpages or web applications.

It’s a nice little package, with pros and cons. The pro is its easy URL namespace to object mapping. The cons are that it’s tied to a multithreaded process model and that it has an oversimplified HTTP request/response model.

The multithreadedness of the framework bit me. My app is a pretty straightforward MySQL/libxslt combination. In profiling tests, the threading (acquire/release/...) cost me about 80% of time, spending most of the rest of the time in parsing the XSLT stylesheet for each request. The latter, I can optimize, but the first I can’t. And I didn’t want to do multithreading in the first place: I’d need to create safe wrappers/pools for both the mysql driver and libxslt! I’d much rather run, say, 4 processes and be done with it.

So, should I dump a Python web framework once again? I don’t know yet. I might delve deeper into CherryPy. I could also ignore its (perceived) problems and continue developing, hoping some WSGI magic will solve my problems in a few months time. Or retrofit my app onto some other framework at some point… Stay tuned.