Curia

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

[Note: This post is the continuation of a series. Please read Round 1 and Round 2 first if you are just now joining us.]

As I briefly mentioned in Round 1, this whole thing came about as an experiment to satisfy my own curiosity. Unfortunately, I wasn’t expecting these posts to draw the amount of attention they have been getting, and several people informed me of a few “issues” with the first round. Since my initial approach to this topic was somewhat casual, I didn’t really take the time to perform each test in a “proper scientific fashion.” Although this was clearly stated in the introduction to round one, it unfortunately resulted in performance estimations that were somewhat less than accurate.

After input from various people much smarter than myself, I quickly went to work tweaking my test environment and building “proper” test apps. In the midst of this, a conversation about PHP accelerators prompted me to put PHP under the spotlight, which brought about Round 2 as an interim round. This gave me a chance to demonstrate the necessity of PHP acceleration, and only continued to solidify my opinion of PHP as an inferior web development language (remember, I just said my opinion).

Which brings us to Round 3. A lot of work has gone into “doing it right” this time, so I am fairly confident that these results are a much more accurate representation of each test subject’s performance estimations. Remember, benchmark test code typically has no real-world value, so “performance estimations” are about all I can promise here. Your mileage will vary. As a wise person once said:

“All this benchmarking is doing is proving what we already know: More code takes longer to execute.” – Ben Bangert (dev lead of Pylons)

(continue reading…)

[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…)