I've run wordpress sites for more than a decade. I've never had an experience with opcode caching that wasn't unhappy.
I've used all of them. They all crash like a demolition derby in a brewery.
At one point I put Wordpress into a profiler and found that a only a few percent of total time was spent compiling PHP; most of the time spent was in waiting for MySQL and concatenating strings. So I just gave up on opcode caching.
The biggest improvements I got were:
* Whole page caching. In my case, WP-supercache spitting out gzip'd pages, with Nginx configured to find and serve those gzip'd pages.
* MySQL query caching.
* Moving MySQL into another server. This was a decent win when I was on spinning rust.
* SSDs. MySQL is a major chokepoint for Wordpress, because until recently its idea of a query plan was "let's join half the workloads on disk in gigantic join tables".
* Killing bad plugins. Even the "recent comments" plugin that ships with mainline is horrendous.
You got some good points here though I don't know why opcode caching didn't work for you. Nowadays, it's just a matter of putting some configuration lines into PHP-FPM config and it works like a charm (at least for me, you might have a special site, idk).
Yes, compiling PHP shouldn't take that much (even though typical WordPress site consists of thousands of PHP files). But as you can see from some of the charts from my work, it can potentially double the amount of concurrent requests the server is able to respond to.
Whole page caching (I call it page cache) is the biggest improvement one can make. However, instead of using WP plugins, in my work I configured Nginx to cache the output of PHP interpreter (FastCGI). The advantages are that you can use Nginx's location directives to bypass the cache early (e.g. logged in users, shopping cart, etc) and that Nginx stores the pages in RAM in a tree-like structure with pretty fast access times. In a heavy WP site (plenty of large plugins, etc), you can go from 200 concurrent requests at 8 seconds to 1000 concurrent requests at 2 seconds, which is a pretty huge improvement.
MySQL query caching should definitely help, though in my testing it did not. Maybe I need a real benchmark with a real 100 people requesting different subpages. Then the DB (MariaDB in my case) might become a bottleneck.
Yeah, SSDs are superb-useful, in any cases. I made all the tests on a non-SSD server. At least the WordPress DB structure is quite flexible, though, as you mentioned, it now suffers from the gigantic joins.
Bad plugins and themes are the root of all the performance problems. But sometimes it is easier to implement caching and replacing Apache with Nginx on the server side than replacing plugins that you really need. That's the main point of the thesis: Time of an experienced developer fixing plugins and themes is more expensive than optimizing the server. But yeah, if you are a developer, learning to write clean and fast plugins is crucial.
It wasn't that configuring opcode caches is complicated or difficult. It's that they locked up every few days, no matter which one I used or how I configured them.
At the point where I wrote a cron script to kill PHP every 24 hours, I realised the extra few percent weren't worth it.
Maybe it's improved, but: four times bitten, twice shy.
> Nginx stores the pages in RAM in a tree-like structure with pretty fast access times.
On disk caching delegates this to the OS, which is pretty good at it.
Badly behaved plugins and themes are not a solvable problem on Wordpress, because it's essentially a cooperative multitasking environment. One bad actor can hog all the resources and there's no way to constrain it.
It seems as though very few plugin authors know what O-notation means (so many nested loops), what EXPLAIN QUERY is or that tinkering and and firing up a copy on your laptop isn't really testing.
> Maybe it's improved, but: four times bitten, twice shy.
I see, happens all the time.
> On disk caching delegates this to the OS, which is pretty good at it.
Yeah, it's just a matter of preference and convenience.
> It seems as though very few plugin authors know what O-notation means (so many nested loops), what EXPLAIN QUERY is or that tinkering and and firing up a copy on your laptop isn't really testing.
This is the real issue. I know a very few WordPress developers who have a formal technical education. While you can learn it yourself, school forces you to learn this in a great detail. In a near future, I will hopefully write on these topics, though, I need to study on this a bit more first.
Well in the old days, the operating system was there to help you. If plugins were standalone processes, they could be resource-constrained. But they all have to run in-process because of the LAMP architecture.
Thanks for the article, it's insightful and I & history agree completely with you. Nowadays, people are using prebuilt VPS images or automation scripts to provision their servers and shared hostings are becoming more of a VPS hostings with a good UI around these tools.
I see that you are a WordPress veteran, nice to hear your opinions :)
I've used all of them. They all crash like a demolition derby in a brewery.
At one point I put Wordpress into a profiler and found that a only a few percent of total time was spent compiling PHP; most of the time spent was in waiting for MySQL and concatenating strings. So I just gave up on opcode caching.
The biggest improvements I got were:
* Whole page caching. In my case, WP-supercache spitting out gzip'd pages, with Nginx configured to find and serve those gzip'd pages.
* MySQL query caching.
* Moving MySQL into another server. This was a decent win when I was on spinning rust.
* SSDs. MySQL is a major chokepoint for Wordpress, because until recently its idea of a query plan was "let's join half the workloads on disk in gigantic join tables".
* Killing bad plugins. Even the "recent comments" plugin that ships with mainline is horrendous.