Curia

[A lot of the information below is out of date. Please see the new framework shootout page for the latest benchmarks.]

Recently I went on a benchmarking spree and decided to throw ApacheBench at a bunch of the different web development technology platforms I interact with on a day-to-day basis. The results were interesting enough to me that I decided I’d take a post to share them here.

Disclaimer: The following test results should be taken with a massive grain of salt. If you know anything about benchmarking, you will know that the slightest adjustments have the potential to change things drastically. While I have tried to perform each test as fairly and accurately as possible, it would be foolish to consider these results as scientific in any way. It should also be noted that my goal here was not to see how fast each technology performs at its most optimized configuration, but rather what a minimal out-of-the-box experience looks like.

Test platform info:

• The hardware was an Intel Core2Quad Q9300, 2.5Ghz, 6MB Cache, 1333FSB, 2GB DDR RAM.
• The OS was CentOS v5.3 32-bit with a standard Apache Webserver setup.
• ApacheBench was used with only the -n and -c flags (1000 requests for the PHP frameworks, 5000 requests for everything else).
• Each ApacheBench test was run 5-10 times, with the “optimum average” chosen as the numbers represented here.
• The PHP tests were done using the standard Apache PHP module.
• The mod_wsgi tests were done in daemon mode set to 2 processes/15 threads.
• The SQL tests were done with mysqli ($mysql->query()) on PHP, and SQLAlchemy (conn.execute()) on Python fetching and printing 5 rows of data from a sample database.

Apache v2.2.3

We will start with the raw Apache benchmark.

For this test, Apache loaded a simple HTML file with random text:

Document LENGTH:        6537 bytes
Requests per second:    8356.23 [#/sec] (mean)

As expected, Apache is lightning fast.

Ok, so now that we’ve set the high water mark, let’s take a look at some popular web technology platforms… (continue reading…)

I recently had to setup a special marketing web-portal for a client of mine that would collect some basic information and throw it into a database to be retrieved later. Since I’ve already got most of the client’s web-stuff on TG2 (and in an effort to keep things DRY), I decided I’d just add a controller for the new pages to TG and use some mod_proxy kung-fu to make it look like it all lived autonomously. Easy enough, right?

Well, about halfway through this process I decided I wanted to have the collected information dump into its own SQLite DB, keeping it safely away from the rest of my client’s data. I had heard that setting up multiple databases in TG2 was supposed to be easy, and with some help from Google I soon ran across this thread on the ML. In it, Chris supplies some very helpful example code which Mike subsequently posted on his blog as a nice tutorial. However, neither of these resources were exhaustive enough to achieve what I was looking for without a bit of “stumbling around”, so in an effort to be overly verbose (and perhaps unnecessarily repetitive) I’ve decided to post what I hope will be a more comprehensive run-down of how to accomplish this task.

Disclaimer: I am in no way a TurboGears or SQLAlchemy expert. There’s probably an easier/better way to do this, but since there’s no “official” TurboGears tutorial on this topic yet I’m afraid this is the best method I’ve found so far. If anyone reading this knows a better way to implement this kind of thing, please leave a comment and I will update this post as the suggestions come in.

Step 1: Define your database urls in the [app:main] section of your .ini file(s)

This is where the magic begins. Instead of one simple sqlalchemy.url = assignment, you’ve got to create assignments for each of the databases you want to use: (continue reading…)

I recently had to wire up an Authorize.net form for a TurboGears project I’m building, and since I’m a bit new to custom form validation in TG I had quite a bit of trouble figuring out the “right” way to do it.

The goal was to get the form to go through two layers of validation before passing:

1. Use the validation packages provided by TG (tw.forms and formencode)
2. If the first layer of validation passes, try to run the authorize.net charge. If this returns a response code of 1 (approved) then all validation has passed. Otherwise, invalidate the form and flash the authorize.net error.

tw.forms and formencode are awesome packages, but at first glance there didn’t seem to be “one obvious way” to do things. I found the documentation and tutorials to be scant at best, and eventually went to the TurboGears mailing list for help. In spite of the fact that I’d probably give TurboGears a “C” at best for its documentation (not to mention the availability of “verbose” tutorials), the folks on the mailing list and IRC channel (when it’s actually active) seem to be quite helpful.

Eventually (and with additional help from Google’s source code search) I was able to hack together something that worked as planned, and was overjoyed to observe chained validators in action. Below is some example code provided for your hacking pleasure. To download the full example file, see the links at the bottom of the post. (continue reading…)