Elliott C. Back: Internet & Technology

Techcrunch has a hilarious exchange of fire between Wordpress founder Matt Mullenweg and Six Apart’s evangelist Anil Dash over the relative merits of Wordpress and MovableType:

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.”

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!

I’ve been getting a lot of Wordpress comment / trackback spam pointing to Squidoo these days, because it doesn’t valid the HTML markup users can enter into their pages. This makes it easy for spammers to put in an iframe with an external src that basically redirects the browser to their spam (usually porn) page. If the javascript were nice it would look like this:

window.onload=function(){
window.location = "http://wpi.biz/in.cgi?5&parameter=porn";
}

The page you get redirected looks like a bunch of adult-themed Youtube vidoes–they’re just images, actually, which I’ve censored–that prompt you to download something that’s probably spyware. I didn’t really investigate this further, it’s obviously very evil:

The code actually sitting on Squidoo’s servers looks like this:

And the comments left on my blogs are of the form:

New trackback on your post #1852 "Coding Horror: Hot Tech Blog"
Website: hot ebony men (IP: 190.72.74.193 , 190-72-74-193.dyn.dsl.cantv.net)
URI : www.squidoo.com/some-nasty-url/
Excerpt: hot ebony men...

I’ve sent email to both the Akismet team and the Squidoo team about this, hopefully they will:

1. Implement kses-based filtering on their html input *immediately*
2. Add some spam-weight to the squidoo domain until this is fixed

There’s no excuse for an XSS attack of this simplicity to exist. Javascript, iframes, etc should be disallowed. Just let basic markup through, and strip out the rest! For now, I also recommend adding the word “squidoo” to your blacklist in the Wordpress discussion options.

Update: According to the Squidoo blog, iframes will banned as of July 12th. I can’t think of anything you can do with an iframe that you can’t do with regular HTML except untrusted stuff, like redirects or arbitrary JS.