Comments on: Solving the WordPress Traffic Overload Problem

By: Epic Alex :: Web Design

Epic Alex :: Web Design — Sun, 13 Apr 2008 23:08:08 +0000

On the issue of integrating a solution into the core of WordPress, I think its pretty interesting that this measure is being taken. The vast majority of blogs would never need such protection, and the ones that do have probably already prepared for the increase in traffic. Is it worth the development time? We’ll see.

On the plus side, having an integrated system as opposed to a plugin can only improve the situation, I’m sure, but is wp super cache not good enough?

By: Jim Hu

Jim Hu — Fri, 11 Apr 2008 08:20:33 +0000

I don’t use WordPress but I suspect that MySQL goes into a trance with large numbers of hits long before Apache. Caching will certainly help that.

I’m surprised that an Instalanche or a Slashdotting raises the numbers of hits above the background of spammers. I don’t get instalanched often, but the last time I got one, it was good for about 8K pageviews, which was only <10% of the total hits on the server for the same period.

By contrast, a recent spam storm on the trackback link, DID bring the same server to its knees. I implemented some countermeasures and things seem to be OK for now (fingers crossed).

By: Stacy

Stacy — Fri, 11 Apr 2008 01:47:05 +0000

From a hosting standpoint, the issue is available apache connections, or available sql connections. There are only so many that a server is configured to answer at a given time. And the configuration depends on the power of the server, ie. a dual xeon vs. a single P4, amount of RAM, etc. etc. We’ve had servers absolutely LUNCHED by sites running Movable Type when a spammer runs a script that hammers at the comment or trackback scripts. Similarly we’ve had servers lunched by sites running WordPress that use plugins that make constant queries against the db.

There is no magic bullet for an Instalanche, or a Slashdotting. When apache/sql are overwhelmed, they’ll restart, which will result in 404s or db connection errors during the restart process, yes. Failover setups are *expensive,* and reserved for those with excessively deep pockets, ala cnn.com, etc. The rest of us have to make do.

By: Jacob Santos

Jacob Santos — Thu, 10 Apr 2008 21:59:58 +0000

Indeed Mark, it is a problem if you are using CGI environment where PHP has to startup and shutdown on each request, but on server environments which only run the PHP startup and shutdown once, have very little overhead with processing scripts. The overhead is pulling in the PHP source files, which is generally small, unless your server configurations are slow, but with Opcaching it pretty much solves that problem as well.

So generally, functions are compiled, which is a fairly quick process for all that PHP has to do. If you think about it, PHP is really fast in compiling large PHP based web applications. So for the functions that aren’t used, you still don’t have that much overhead. You might save a millisecond or two, but that is only a millisecond or two, which is less than a thousandth percent of the total time it takes.

The overhead comes when you have to enter the function stack and that is interesting with its overhead. During the performance tests for the plugin API fix, I encountered that the Plugin API is faster if it had code duplicated in multiple files instead of placing it in one function and used in each of the functions. You see it because the Plugin API is used very often, so not having the code separate would save time, but would require updating more than one area and from past commits and patches, it is known that not every duplicated area is fixed. So if you have three places and only fix one or two, then you still have one area that needs updating. Anyway, that is a tangent, so I’ll get back on topic.

Basically, the PHP Engine is not the problem, unless you really, really have a lot of visitors, like Yahoo, where every millisecond counts. Then you’re better off writing an extension for the slow parts.

By: Donncha O Caoimh

Donncha O Caoimh — Thu, 10 Apr 2008 21:41:09 +0000

PHP is only really a problem when there’s a very very high load. A PHP cached page will eventually cause the load to rise faster than a static html file served with a mod_rewrite rule.
Of greater concern is the load generated by queries on the db. A rampaging scraper bot hitting 10 uncached archive pages simultaneously can bring my reasonably well equipped VPS to it’s knees. When those pages are cached as html files the server hardly notices of course!

By: Mark Jaquith

Mark Jaquith — Thu, 10 Apr 2008 19:21:35 +0000

From a technical standpoint, the problem is that PHP is entirely loaded into memory for every pageload. That includes the 99% of PHP that is not being used to actually render the page.

I don’t think PHP itself is the problem. The most benefit when dealing with high-load situations comes from not having to do a dynamic WordPress load — even if that caching solution requires PHP. The WP-Super-Cache solution is nice, and it certainly gives you some incremental benefit above a PHP-powerered output cache, but it requires

1	mod_rewrite

, and thus excludes a certain segment of WordPress users. Out solution is going to have to be much more generally usable.