httpdocs/wp/ -> WP Install
subdomains/gadgets/httpdocs/ -> /elliottback.com/httpdocs/wp/
subdomains/books/httpdocs/ -> /elliottback.com/httpdocs/wp/

This means that from my domain, we’re always sticking an extra /wp onto things, but from the subdomains, they go directly into the wp-content directories from the root , in both relative and absolute sense. I consolidated my subdomains this way so that I could run a single WP install and maintain them together. Here’s the .htaccess file that lets WP Super Cache work on either of them:

# BEGIN WPSuperCache
<ifmodule mod_rewrite.c>
RewriteEngine On
AddDefaultCharset UTF-8
RewriteBase /
RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{REQUEST_URI} ^(/wp)?/
RewriteCond %{DOCUMENT_ROOT}%1/wp-content/cache/supercache/%{HTTP_HOST}/%1/$1/index.html.gz -f
RewriteRule ^(.*) %1/wp-content/cache/supercache/%{HTTP_HOST}/%1/$1/index.html.gz [L]

RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{REQUEST_URI} ^(/wp)?/
RewriteCond %{DOCUMENT_ROOT}%1/wp-content/cache/supercache/%{HTTP_HOST}%1/$1/index.html -f
RewriteRule ^(.*) %1/wp-content/cache/supercache/%{HTTP_HOST}%1/$1/index.html [L]
</ifmodule>
# END WPSuperCache

Let me know what you think–performance stats show that it’s working fine for both the /wp subdirectory and the other subdomains!

1. Without any caching plugins
2. With WP Cache 2.0
3. With WP Super Cache (no compression)
4. With WP Super Cache (compression enabled)

The results show that WP Super Cache is a clear winner, performing 225% better than the older WP Cache. Here is the raw data I gathered during the test:

No caching:
Requests per second: 22.81 [#/sec] (mean)
Time per request: 4383.559 [ms] (mean)
Time per request: 43.836 [ms] (mean, across all concurrent requests)
Transfer rate: 613.75 [Kbytes/sec] received

WP cache:
Requests per second: 872.30 [#/sec] (mean)
Time per request: 114.640 [ms] (mean)
Time per request: 1.146 [ms] (mean, across all concurrent requests)
Transfer rate: 23549.46 [Kbytes/sec] received

Super cache (no compression):
Requests per second: 1518.90 [#/sec] (mean)
Time per request: 65.837 [ms] (mean)
Time per request: 0.658 [ms] (mean, across all concurrent requests)
Transfer rate: 41150.81 [Kbytes/sec] received

Super cache (compression):
Requests per second: 1960.39 [#/sec] (mean)
Time per request: 51.010 [ms] (mean)
Time per request: 0.510 [ms] (mean, across all concurrent requests)
Transfer rate: 53108.70 [Kbytes/sec] received

For more tips on how to improve your Wordpress performance, check out Wordpress Performance: Why My Site Is So Much Faster Than Yours. Another interesting WP caching plugin is Batcache, which uses the memcached backend to serve requests out of a cluster of machines’ RAM memory.

The main page has been refreshed in boring, pastel colours, and prominent links to their Wordpress for Dummies book via Amazon affiliate link and their hosting affiliate suggestions have been added. I’m honestly not impressed with the redesign, which has included work on the administrative interface:

It’s as if they took the strong ideas and colors of Wordpress past, watered them down, spaced them out, and made sure everything looks sufficiently web 2.0 without actually adding a substantial improvement. Every administrative screen now looks different and inconsistent with the others. If I upgrade, I’m definitely going to miss the old theme. On the other hand, no work had been done since Wordpress 1.5 on the administrative look and feel, so any work, regardless of how it feels, is welcome. Perhaps this is just a stepping stone to a truly better admin panel?

The WP 2.5 release notes blog post indicates some other nice changes:

• Multi-file upload with progress bar
• EXIF extraction (the photobloggers will love this)
• Password strength meter
• Few-click plugin upgrades (I am expecting some 0day exploits here)
• Built-in galleries
• A new Shortcode API (Isn’t this just BBCode ripped off?)

I’ll probably end up installing this with the next release of my own blogs and themes, as the features look promising.

Anil Dash: “WordPress 2.5 is about to be released, and we wanted to encourage WordPress users to upgrade. To Movable Type.”

Matt Mullenweg: “Six apart is getting desperate, and dirty.”

Anil Dash: “Desperation is resorting to name-calling and slander instead of substance — if there’s a factual error, i’m glad to fix it.”

I’ve written before about how I personally prefer Wordpress to Movable Type because it offers me an unprecedented open source experience, tons of community support, and easy hackability. It’s also pretty damn fast, so I don’t worry about my server crashing or overloading.

However, it’s also totally ok in the competitive marketplace of free blogging software for one manufacturer to directly tote its own features in comparison to another piece of software. What’s wrong with saying that Movable Type has features x, y, and z that Wordpress is still dreaming of?

Update: Mullenweg, of Wordpress, has followed up his Twitter with a post Wordpress Is Open Source, in which he says “I had held off criticizing [MovableType and Six Apart] after they went OS and before they decided to start an all-out confrontation because that’s not generally what OS projects do to each other.”

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!