Elliott C. Back: Internet & Technology

Ignoring any of Hongli Lai’s actual code, I reran the PHP, Ruby, C++, Perl, and Python mergesort benchmarks he gave, and came up with substantially different results. Here are the versions of the programming languages I am using for the test:

• PHP – PHP 5.1.6 (cli) (built: Sep 18 2007 09:07:28)
• Ruby – ruby 1.8.5 (2007-09-24 patchlevel 114) [x86_64-linux]
• Perl – This is perl, v5.8.8 built for x86_64-linux-thread-multi
• Python – Python 2.4.4 (#1, Oct 23 2006, 13:58:18)
• C++ – gcc version 4.1.2 20070626 (Red Hat 4.1.2-13)
• Java – Java(TM) SE Runtime Environment (build 1.6.0_10-ea-b10)

You’ll notice I’m adding Java into the mix for fun. Here’s the results, over 10 runs, on an Intel Dual-core 1.80GHz machines with 2Gb of RAM currently running this website:

Lang	Average	Min	Max
PHP	8.8325	8.637	9.303
Ruby	7.2896	7.143	7.729
Perl	4.3231	4.262	4.428
Python	3.3465	3.289	3.417
C++	0.5638	0.53	0.609
Java	0.4062	0.262	0.551

There are a couple important conclusions to note here that are significantly different than Hongli Lai’s:

• PHP is 21% slower than Ruby, not 41% as in his benchmark
• Python is 29% faster than Perl, not 17% as in his benchmark
• Java runs this 39% faster than C++, and 2100% faster than PHP

So, PHP is slower than Ruby, but not quite as slow as Hongli Lai would have you believe. Python is the fastest scripting language in this benchmark, while Java is the faster language all around, and is incredibly, incredibly fast. Maybe all of our code should start using java!

* NOTE: I am ignoring the obvious deficiencies of this micro-benchmark and just trying to reduplicate it. What I’ve found is that there are significant discrepancies between Hongli Lai’s run of the tests and my own, probably owing to slightly different versions of the components involved. Also, if I make some trivial optimizations to the loops in the PHP script, I can get it to run faster than everything but C++, in about 2.4s. Then again, just calling sort() is faster by another two orders… but still half as slow as Java’s built-in sort… and two orders slower than perl’s built-in.

Today at the Macworld 2008 Expo, Steve Jobs released a new version of the Macbook called the Macbook Air. Unlike last year’s iPhone announcement, the response to the Air was negative. The price of Apple’s stock today dropped 9.02% to close at $169.04 and $163.01 in after-hours trading:

If you’re interested in the Macbook Air, check out these specifications from the Apple Store. For $1799, you get a 0.76 inch thick, 3.0 pound notebook with a 13.3 inch backlit widescreen display, 1.6 GHz Core2 Duo processor, iSight camera, backlit keyboard, and multi-touch trackpad. It has a single USB 2 slot and a single micro-DVI slot and headphone jack via a door on the side. Wirelessly, it supports 802.11n and Bluetooth 2.1/EDR. It has no optical drive natively, and comes with a wimpy 80GB 4200 RPM hard disk. A 1.8 GHz processor and a 64GB solid-state drive (SSD) will cost $3,098.

I have to agree with Michael Arrington of Techcrunch that the laptop, even as a premium option, is grossly overpriced and underpowered. A slightly heavier, but significantly more powerful Sony Vaio (40% faster CPU, 30% faster hard disk, more ports, fingerprint sensor, nvidia graphics, twice as much hard disk space, slightly thicker, slightly heavier, same height and width) can be bought for $1800. If you go to Dell, you can configure their 13.3-inch widescreen XPS M1330 with an SSD drive and a few upgrades for just $2,404, a significant savings over Apple’s price.

It’s interesting that Kineda and Paul both point out seriously problems with the new Macbook (it’s wimpy, overpriced, and full of proprietary non-replaceable, non-upgradable parts) but still cheer it on. Paul says,

News flash to Devin people don’t buy ultraportable notebooks for their workstation-like performance. Enough said. Do I want one? Hell yes.

But, it’s Daring Fireball who finally gets to the bottom of the Macbook Air, and why it sucks. It just doesn’t make the right design choice! Thinner is not the same as smaller; we want a 12″ or 11″ or 10″ model, both smaller in form factor and thinner and lighter to boot:

I’d have rather seen a smaller footprint, a la the old 12-inch PowerBook G4 — something just exactly as wide as a full keyboard. I’d prefer to sacrifice screen size on the notebook in exchange for an even smaller machine.

Update: Did you know that five years ago, Sony made the Vaio X505, a laptop .8″ thick? Pwnt, Apple. That’s all I can say!

A lot of people talk about Wordpress performance, and how to get a webserver to perform as efficiently as possible. However, without a quantifiable methodology to testing website performance, you can’t actually talk about it. ApacheBench (ab) is the solution to the problem of measuring website performance. What is ApacheBench? The man page provides a suitable answer:

ab – Apache HTTP server benchmarking tool

ab is a tool for benchmarking your Apache Hypertext Transfer Protocol (HTTP) server. It is designed to give you an impression of how your current Apache installation performs. This especially shows you how many requests per second your Apache installation is capable of serving.

If you have installed apache or apache-devel, you should be to simple invoke ab by typing it on the command line. For example, to benchmark my own site here, I would write:

[root ~]# ab -n 10000 -c 100 http://elliottback.com/wp/

This says “make 10,000 concurrent requests to host elliottback.com via http and request /wp/ on 100 threads.” The result of this is the following report:

This is ApacheBench, Version 2.0.40-dev < $Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking elliottback.com (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Finished 10000 requests

Server Software: Apache/2.2.6
Server Hostname: elliottback.com
Server Port: 80

Document Path: /wp/
Document Length: 34331 bytes

Concurrency Level: 100
Time taken for tests: 13.596345 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 346230000 bytes
HTML transferred: 343310000 bytes
Requests per second: 735.49 [#/sec] (mean)
Time per request: 135.963 [ms] (mean)
Time per request: 1.360 [ms] (mean, across all concurrent requests)
Transfer rate: 24868.08 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 1.6 0 20
Processing: 8 134 12.7 132 190
Waiting: 4 134 12.7 132 190
Total: 16 134 12.1 132 190

Percentage of the requests served within a certain time (ms)
50% 132
66% 134
75% 136
80% 137
90% 145
95% 160
98% 175
99% 179
100% 190 (longest request)

According to these numbers, my dual core server can do 750 requests per second, fulfilling each within about 150ms each. That’s pretty fast, probably because I know the secrets of Wordpress Optimization. If you make every layer as fast as it can be, and cache heavily, you too can see lightening fast Wordpress installations!