Hardware Specs for WordPress Applications

Your team has been working on that perfect WordPress project for months, it’s been tested and is ready to fly. You get some nice cloud server. Your application survives your first handful of users, gains more traction only to stumble and stall.

Your users experience timeout errors, dragging load times and a frustrating experience overall. And you turn to your hosting company for some insight.

Both managed and unmanaged, dedicated and shared, cloud and container hosting companies out there are in the business of selling RAM and CPU. Their support teams will encourage you to buy more for more performance gains without really delving into what you’re running and why it’s performing poorly. If you’d like t

Thus, in a never-ending cycle, hosting providers out there are in a battle trying to provide better specs, higher RAM numbers, more CPUs and CPU cores, fancier usage terms for less money. Many will find ways to oversell and underdeliver. But that’s not the real issue here.

The real issue is that 99% of the time shelling out for a beefier server is a mistake. WordPress application performance does not scale linearly with RAM and CPU cores, as a rule (with rare exceptions). Sure it will somewhat help, until you hit yet another milestone in user activity and face the same issue. A vicious cycle that leaves you with a 256 GB RAM and 64 CPU machine serving a 10,000 visitors per day. Ridiculous!

While it is counter-intuitive you need to forget RAM and CPU and instead start profiling your application code to find bottlenecks and fix them. Here’s a simple example to show you how throwing money blindly at higher numbers wouldn’t help one bit.

WordPress Profiling UI
WordPress Profiling UI

Consider the following code in your application that communicates with an external API:

$response = wp_remote_get( 'http://api.example.com/v1/ping' );

Let’s say this response takes 2 seconds to complete. All your visitors are waiting for your code, which in turn is waiting for the remote HTTP response. Your RAM usage is a mere 5MB for the hit, all of your 64 CPUs are idle, but you’re paying for it all.

Such requests cascade on top of one another all waiting until your backlog is filled up and further visitor requests are rejected. So much for all that idle power. By fixing that remote call you might find out that your application runs orders of magnitude faster, and a $5 Digital Ocean VPS is enough for months to come. True story.

Thus, the real question is:

Do you know your code?

Static caching aside, do you know how much CPU time and RAM each request consumes? How expensive are your IO-bound operations? Are you sure you have no concurrency issues like PHP session locks? What about your static cache hitrates, are they in order?

If you can’t answer these questions, then your development team is probably doing a poor job, or you’re not paying them enough ;)

We understand that many teams lack the resources to thoroughly battle-test their applications. Moving quickly and breaking things, WordPress application performance and scalability is skimmed over. And this is how Pressjitsu started.

Pressjitsu

We’re not in the business of selling RAM and CPU cores, we’re selling our WordPress expertise and experience, deep understanding of how WordPress works internally, our support and tool that we’ve built around our platform. It is our priority to squeeze the most out of our carefully-configured cloud infrastructure.

Our team studies your code, points out the bad parts and consults you on how your team should mitigate the issues that arise thereby. Often, 80% of performance gains come with the least effort and by using a sane server configuration (we use PHP7 and nginx, for example). The other 20% come at later stages, from analyzing historical performance graphs, error and warning logs, slow queries in MySQL, etc.

That is when most of our WordPress performance articles are born, because we love to share our knowledge. Seeing poor-performing code makes us sad. Seeing poor-performing code on crazy server setups makes us even more sad.

That’s pretty much what it runs down to really. A brilliant server configuration, geared towards performance for WordPress, and a dedicated team that is constantly squeezing every last CPU cycle out.

Again, we’re not selling servers, by offering you more RAM we’re not making any more money. We’re selling our support, making sure your WordPress site runs faster than ever.

Remember, poor performance translates into uncontrolled and inefficient hosting expenses.