[tiredofcareer]

You need a cache in front of Wordpress so that it doesn't hit the database on every read, then you can run Wordpress anywhere. I survived close to 3,000 req/sec against a Wordpress entry using a single Linode 360, back when those were available.

wp_supercache, nginx, varnish, etc. Rinse and repeat.

[jacques_chester]

I appreciate the advice, but I knew this already. I've been using WP Supercache since it was released. Nginx for I think 4 years at this point. I have it configured to the point that nginx serves the gzipped pages WPSC writes out to disk without ever hitting PHP.

I have three words for you:

Recent.

Comments.

Widget.

[dugmartin]

It's been a few years since I worked on a large WP install but I wonder if you could write a plugin that replaced the comments section with an esi (edge side include) directive. That would allow Varnish to cache the whole page and then call into WP using the url in you esi include to build the comments section. You could also then set the ttl on esi comments url so that you can fragment cache the comments for non-logged in users (for say 10 seconds).

More info here: https://www.varnish-cache.org/trac/wiki/ESIfeatures

[jacques_chester]

It's funny you should mention this. I was chatting to a mate about this thread and he suggested using an ESI approach.

I think it would work well if the Recent Comments widget was modified to spit a HTML fragment to predictably-named files that varnish could pick up and include with ESI.

[SonOfLilit]

I never installed Wordpress in production, this is the first time I hear about ESI and in general have almost no relevant experience, but maybe this suggestion has some worth:

ESI sounds like it would couple your web application code to your cache. This sounds negative to my ear. How about modifying the Recent Comments widget to work with an IFRAME or some AJAX? It adds another request to the server, but now both requests can be cached and compressed.

[jacques_chester]

I wouldn't mind coupling Wordpress to Varnish, since I'm controlling my particular installation.

An ajax solution isn't a bad idea, though it would mean at least hitting PHP (whereas the Varnish option never gets that far).

[tiredofcareer]

That's why Varnish is more effective, because you can configure it to cache the results of things that WP Supercache misses by design including the Recent Comments Widget and its data. If you need SSDs to run Wordpress, there's a flaw somewhere. Every time I've scaled Wordpress, caching has been the answer. Apply liberally.

WP Supercache is a hack anyway, for folks running WP on shared hosts without root. If you have root, there's a plethora of better things for caching, even as ancient as Squid as a reverse. You can get your MySQL traffic down to <1 QPS fairly trivially, no matter what kind of traffic is hitting the frontend.

Don't forget wordpress.com is a huge MU installation, and they've existed since before SSDs became popular. The disk is not your issue here.

[jacques_chester]

Varnish is not effective in the face of Recent Comments because that widget breaks whole-page caching fatally. Every time anyone leaves a comment anywhere, the entire cache for the entire site is invalid.

When I looked at where the slow runtimes were occurring on Linode, it was always jammed on disk I/O and it was always on PHP functions that are reaching into MySQL.

In my experience the MySQL query cache + an object cache do more for sites with a Recent Comments widget than whole page caching.

As it happens, I do all of the above. And I was doing all of the above. And still getting jammed on I/O. Because MySQL likes to join on disk. Whole page caching is useful only if you prevent that from happening. It's useless if the cache is rendered invalid every few seconds on a chatty site.

[tiredofcareer]

    set beresp.ttl = 30s;

Varnish gives you your own throttle for how often you want invalidation. It's a tool specifically designed to make misbehaving apps -- i.e., that widget -- misbehave. You just have to slap the dog on the nose when it behaves. I'm just saying you could have made this work on Linode (and I have), but I do see your post-purchase rationalization at work, so I know anything I say will be fruitless anyway.

There's also the possibility that you had shitty neighbors.

[jacques_chester]

Right, and when I hosted on WPEngine and then on Pagely (and both of them choked), my users immediately piped up that the recent comments were inaccurate. In fact there were a number of page freshness anomalies which I believe were down to whole-page caching that I was frequently quizzed about by users.

If your page is basically static, then yes, whole-page caching will fly. But several of the sites under my supervision are, to quote Pagely's founder, used "like a chat room".

Edit, per your edit:

> I'm just saying you could have made this work on Linode (and I have), but I do see your post-purchase rationalization at work, so I know anything I say will be fruitless anyway.

Basically, I was there, I saw the numbers and I know why they wound up looking the way they did. I suspect that anyone in my particular situation would have evolved their approach in the same way that I have. I've been running Wordpress blogs since 2004. I feel that I've picked up some ideas on how to make it fast, but sometimes the general solutions don't work because you have a specific problem.

[tiredofcareer]

Got it. So you have users that expect to have real-time conversations in the comments on a blog, meaning you can't optimize a blog application like a blog is designed to be used, meaning you have to pay for SSDs in order to make your blog function at all because apparently MySQL can't handle N inserts/second and however many people have these conversations refreshing every ten seconds, generating a few SELECTs that are rapidly in query cache.

I completely understand how this could be a problem and how switching providers would fix it.

[tuananh]

that popular posts widget sucks :D