I’ve been playing with Python for close to two years now. I started out playing with Python when I had a need to develop web applications faster. I was getting rather bored with the additional development time that the thousands of lines of XML and the constant restarting of Tomcat that the Java, Struts, Hibernate, et al. stack was adding to my workload. Anyway, at the beginning of my Python journey, I began evaluating a few different Python web frameworks. After these couple of years, I’m ready to record a few of my thoughts on the process.
TurboGears
Until this point, I’ve used TurboGears exclusively for the web applications I’ve deployed. As far as the development environment is concerned, TurboGears is pretty hard to beat. In addition to providing many widgets for common use cases of web applications, you get a database admin utility and a number of tools that help automate tasks like internationalization.
What you also get with TurboGears is a hard wired dependency on CherryPy. As a developer, I’m not really for or against CherryPy. The ability to run my applications locally with minimal setup is quite nice. As a system administrator though, having to manage a CherryPy application was not fun. One of the reasons I originally ditched Java was the additional application server that had to be managed. While it is true that you could run Tomcat by itself, many situations require an Apache or other web server and Tomcat had to be proxied. This is especially true with CherryPy. The versions of CherryPy required by TurboGears 1.x didn’t support HTTP 1.1, let alone SSL.
In my opinion, the best way to use a server side language is to have it integrated into your primary web server. PHP is successful because mod_php just works. While I’m not as familiar with the mod_perl community and it’s degree of success, I’m pretty sure that mod_perl works quite nicely. Perhaps someone can comment and provide insight on that front. By following this line of logic, you’d think that the best way to deploy a Python application to the web would be with mod_python. While there is a method of deploying TurboGears/CherryPy with mod_python, it has been noted to be extremely slow. In my own tests, I found this to be the case. I also found other problems with session management when attempting to get a TG application to run with mod_python. That leaves you with a fast cgi or mod_proxy alternative. Of the installations I’ve read about, most people suggest proxying and there are a few that use fcgi. You’re back to square 1 with having to manage two production servers for one web application though.
Next on my TG chopping block is it’s state of development. Originally, TG made a lot of progress and was rapidly becoming a very useful product. It has been noted that many open source projects suffer from burnout or a lack of interest in the middle stages. This seems to be especially the case with TurboGears. Somewhere around the release of version 1.0, the project was handed to the community. Since then, it seems more common to have long discussions about which templating engine should be used rather than to see issues resolved and features slated. I don’t want to sound especially negative though. The decision was made a while back to base TG 2.0 on Pylons instead of CherryPy. This can only be a good thing in respect to my first argument but it isn’t ready for use yet. I imagine TG 2.0 will be worth re-evaluating in the future.
Pylons
I originally didn’t investigate Pylons for a couple reasons. First, at the time, it wasn’t very mature. Second, I was quite content and having success with TurboGears and didn’t have a lot of time to do extra research if it wasn’t especially needed. Lately, my interest has been piqued and I decided to run a few tests.
Unlike the sad state of the TurboGears mod_python integration, Pylons has a couple pretty good alternatives. I decided to set up a blank application with Pylons and serve it up in a couple different ways. Here are the results:
-
Paster
Paster is the Python utility that configures, adds to, and can also serve your Pylons application. It’s internal server can be proxied much the same way CherryPy can be proxied behind apache. I didn’t try the proxied method because part of my whole reason for ditching TG is to avoid managing a separate server. Instead, I wanted to see how this simple server handled the default page with a new Pylons application. It should be noted that Apache can serve the same exact default Pylons application index page, when it is saved as a static html file, at the rate of about 1400 requests/second.
# setup a new Pylons application
> easy_install pylons
> paster create --template=pylons somesite
> cd somesite
> paster serve development.ini
Starting server in PID 8475
serving on 0.0.0.0:5000 view at http://127.0.0.1:5000
There, easy enough. Now I’m going to run the apache bench test from another machine:
Document Path: /
Document Length: 3028 bytes
Concurrency Level: 25
Time taken for tests: 0.968094 seconds
Complete requests: 500
Failed requests: 0
Write errors: 0
Total transferred: 1647000 bytes
HTML transferred: 1514000 bytes
Requests per second: 516.48 [#/sec] (mean)
Time per request: 48.405 [ms] (mean)
Time per request: 1.936 [ms] (mean, across all concurrent requests)
Transfer rate: 1661.00 [Kbytes/sec] received -
Mod Python
Next, I used the Pylons mod_python wsgi adapter method. Here is the same exact page but served with Apache/mod_python instead of Paster:
Document Path: /pytest/
Document Length: 3028 bytes
Concurrency Level: 25
Time taken for tests: 0.736244 seconds
Complete requests: 500
Failed requests: 0
Write errors: 0
Total transferred: 1666000 bytes
HTML transferred: 1514000 bytes
Requests per second: 679.12 [#/sec] (mean)
Time per request: 36.812 [ms] (mean)
Time per request: 1.472 [ms] (mean, across all concurrent requests)
Transfer rate: 2208.51 [Kbytes/sec] received
The mod_python version looks to be faster. Admittedly, the difference isn’t extremely notable, but my purpose for this test is simply to determine whether or not mod_python is a feasible deployment option. It would appear, at least initially, that I’ll be satisfied in the long run.
What’s Next
At this point, I’m ready to create something with Pylons. As with any framework (in any language), I’m sure there are issues that need to be worked around. I don’t think the actual framework matters as much as the ability of the developer to get jobs done with it. For me, I think Pylons will suffice for the time being.
Perhaps you should also take a look at web2py (http://www.web2py.com). All in one box, faster than anything else and no need for installation instructions. It is wsgi compliant and used to be based on paste.httpserver but now uses cherrypy.wsgiserver which is faster and supports streaming for large files. We also provide apache and lighttpd handlers for production environments.
Here are some cool example applications: http://mdp.cti.depaul.edu/appliances
Have you tried django? The benchmarks i’ve seen for it are impressive, typically faster other current frameworks.
I’m not as worried about the speed with Django as I am the development model. It seems if you are out to do exactly what Django is good at doing then you won’t have any problems. Customization starts slowing you down and giving you issues. Also, I really like SQLAlchemy and Django isn’t very friendly with swapping components out I’ve heard.
Hey Dennis,
I have been testing some frameworks (PHP and Python) and I havent decided for any of them. I have been doing this for a year almost. So I would like to ask: What framework do you like most? Are you still using Pylons?
Thanks a lot!
I was still using Pylons as of the last time I did some web stuff. For the last year, I’ve been working with circuit boards and firmware though so I’m afraid I can’t give much of an update. I’m sure all the frameworks have progressed since this post was written. I wonder if TurboGears 2 (which was supposed to use Pylons) ended up any good. Django might be good depending on what you need too.
HUmmm, I see. I am looking for a framework to stick with, and do a lot of stuff, and build a big system. The main constraint is I dont want to have a server running, like tomcat. Mod_python should do the job! 🙂