performance

The title is a quote from Nikita Prokopov, who is wallowing in disenchantment.

The Loop’s Jim Dalrymple compiled the following numbers for the time it takes various tech sites to load in a browser in late 2011:

• The Loop: 38 requests; 38.66KB; 1.89 secs
• Daring Fireball: 23 requests; 49.82KB; 566 milliseconds
• Macworld: 130 requests; 338.32KB; 8.54 secs
• Ars Technica: 120 requests; 185.99KB; 2.08 secs
• Apple: 46 requests; 419KB; 1.39 secs
• CNN: 196 requests; 269.41KB; 4 secs
• BGR: 368 requests; 2.74MB; 35.33 secs
• AppleInsider: 141 requests; 649.39KB; 5.64 secs
• Facebook: 137 requests; 993.54KB; 11.19 secs
• MacStories: 119 requests; 2.16MB; 2.13 secs

John Gruber started this by calling out The Next Web for it’s slow performance:

• TheNextWeb: 342 requests; 6MB; no time info

More benchmarks can be seen at Browsermob.

Regular Expression Matching Can Be Simple And Fast, by Russ Cox:

Perl [and PHP and others] could not now remove backreference support, of course, but they could employ much faster algorithms when presented with regular expressions that don’t have backreferences.

How much faster? About a million times (no, I do not exaggerate).

I use a lot of regular expressions, and relatively few of them use backreferences. It’d be worth optimizing.

What is the current status of web servers…Is Apache 2.x “fast enough?”

Automattic uses Lightspeed (for PHP), nginx (for static content), and Apache (for media uploads). For WordPress-generated content, all server options are approximately the same speed.

What about APC?

Automattic uses beta versions of APC, and provides a 3-5x performance increase. It’s tied closely to the PHP version, so Automattic recently switched from PHP 4 to PHP 5.

Databases?

MySQL scales well and is easy enough to use that there’s little reason to consider other DBs for WordPress content. Other applications may have different needs. Note: FriendFeed uses MySQL to store schema-less data. Single-table key lookups in MySQL are faster than getting the data from Memcached.

Caching?

Automattic uses Batcache for full-page caching (.002 to .003 second), Memcached persistent object cache, very limited MySQL query cache (never larger than 256MB), sufficiently large key buffer.

HyperDB?

HyperDB solves DB scaling problems.

Backups

User-data backed up every hour, if something changed. Every blog backed up every 12 hours. Dedicated MySQL slaves do LVM snapshots for backups.

This two year old post about Rasmus Lerdorf’s PHP scaling tips (slides) is interesting in the context of what we’ve learned since then. APC now seems common, and it’s supposedly built-in to PHP6. Still, I’d be interested in seeing an update. Are MySQL prepared statements still slow?

And that’s where Rasmus’ latest presentation comes in. We don’t learn anything about MySQL prepared statements, but we do learn how to find choke points in our applications using callgrind and other tools. In his examples, he can do a little over 600 transactions per second with both static HTML and simple PHP, but various frameworks — with many inclusions and function calls — can slow that to under 50 transactions per second (I suppose they’d explain that in a TPS report).

WordPress.com VIP hosts some high-traffic sites, including Gizmodo’s live coverage of the iPhone 3g introduction. Now that the NFL has selected the service for their blogging we’ll get a chance to see how they handle the Superbowl rush.

Hearing Steve Souders at WordCamp last week got me thinking about website performance, so I went looking for more. The slides from his WordCamp talk are online, but he gave a similar talk at Google I/O which got videotaped and posted richer detail than his slides alone will ever reveal.

Also on his blog: Use the Google AJAX Libraries API when you don’t have a CDN, and a post that asks why make users wait to download all your javascript before they see the page if you’re only going to use 25% of it at first?

Google turned this up, but i have no idea how old it is: How to Monitor MySQL’s performance.

Emil Ong is the Chief Evangelist and a lead developer for Caucho Technology, the developers of the Quercus PHP to Java compiler. The idea, I guess, is to write in PHP, deploy in Java, which some people say is better supported by the “enterprise.”

Ong claims 26% performance improvement over Apache + mod_php + APC. That sounds great, I suppose, but it’s less than what Chris Lea suggests is possible if you simply replace Apache with Nginx.

Steve Souders: 10% of the problem is server performance, 90% of problem is browser activity after the main html is downloaded. He wrote the book and developed YSlow, so he should know.

JavaScripts are downloaded serially and block other activity. Most JavaScript functions aren’t used at OnLoad. We could split the JS and only load essential functions up front, and load all the rest later. How much might that help? He says 25% to 50%. This quickly gets complex, but he’s got a simple plan that considers three questions:

• Is the script URL on the same host as the main HTML?
• Should the browser indicate it’s busy, or not?
• Does script execution order mater?

And at that point things started to get too interesting to take publishable notes. I clearly need to pay more attention to this guy.

Stats he mentioned without being specific about the source:

• Google: 200ms longer download time cut revenue by 20%
• Yahoo: 100ms of latency costs … big.

Elliott C. Back points to his use of object caching, WP-Cache, and MySQL query caching among the reasons why his site “is so much faster that yours.”