The contents of this article started from a post in our Facebook group with some misunderstandings there are when it comes to “tuning” your server settings for performance.
That post resulted in this post in our Community Forum, and this article is essentially the contents of that post made public.
TABLE OF CONTENTS
Improving Performance at a Managed Host vs vCanopySome context that I believe will be helpful here is the options that are available to you at a traditional “managed” WordPress host vs vCanopy. In the context of improving your WordPress sites performance at the server level, at a managed host you can:
- Turn caching ON
Improving Performance at vCanopyvCanopy also offers WordPress optimized server-level stacks. They will work great out of the box for 95% of all websites. The difference where I think most people go wrong on our platform is that you have so much control, and so many more options available to you compared to essentially any other host, and by a huge margin. And with so many settings, what should you focus on to improve performance? There are 2 main things on vCanopy you should pay attention to:
- Use our server page caching and Redis object caching
- Make sure your PHP workers aren’t totally misconfigured – a good rule of thumb is 3-4 workers per 1 vCPU. If you have a heavy codebase, go with 3. If your server has multiple sites, use Dynamic. If it’s just one website on the server, choose Static for better performance under load.
- Check your database for MyISAM tables. If any exist, convert them into InnoDB tables.
- Run MySQL tuner and implement its recommendations (A KB doesn’t exist for this yet, but it is on my to-do list)
- Turn on WPFail2Ban and 7G to reduce useless, malicious bot traffic that can use up your server resources and cause performance issues
Learning More About Caching and WorkersFor Nginx servers, you can learn more about whether you should use Redis page caching or FastCGI caching in their respective articles below. The really short version is that if you have very high concurrent traffic, then FastCGI will handle high concurrent load better than Redis will. Also, if a site is publishing a lot of content regularly but clients are complaining their changes aren’t showing up on the live site, switching to FastCGI will save both of you some headaches – more details in the KBs:
Further Performance ImprovementsYour server settings are 1 of 3 ways to improve your website’s performance. The other two are:
- Improve your website’s codebase and optimize your database to clear out any unnecessary bloat
- Use better hardware (or just more of it)
Bonus Points:OK, technically there is a 4th option that will reduce server overhead, and that’s using a service like Cloudflare or a CDN. These services will both improve your speed around the globe (in most cases), and reduce the amount of work your server has to do to serve your websites to your visitors. How much benefit you’ll actually gain depends on the type of website you’re running.
Questions and Answers
What about load balancers?If you’re not sure if you need a load balancer, then you don’t need a load balancer. If you’re not maxing out at least a dedicated server with 32 high-frequency cores (gaming servers ideally), then you’re not at the point where you need a load balancer, and using one would cost you a lot more in time, effort, complexity, and maintenance, and likely also money, than just using a bigger server would cost you.
What about troubleshooting and diagnosing server performance?From a server optimization perspective, all the info you need is above. Most of the time when people are talking about improving performance what they’re really talking about is fixing 502/504 issues which in 95% of cases are the result of codebase issues, and tweaking server settings really isn’t going to help, or at best will act as a bandaid to keep it limping along. The remaining 5% is usually that you just need a bigger server For troubleshooting, you need to be able to identify which site on a server is causing the load (check
htop to identify which websites are the most active), and then determine whether this is a legitimate rush of traffic, an attack, or just long-running requests due to a plugin locking up the database or serious PHP inefficiencies.
Each of these requires a different resolution.
For this, these two guides cover what I believe everyone on vCanopy should take the time to learn:
- Sites are Down! Part 1: Here’s What Everyone Needs to Know
- Sites are Down! Part 2: Practical Troubleshooting
How do I differentiate between a caching issue, vs memory issue, vs CPU issue, vs PHP-FPM issue?
- Clear the cache (and Cloudflare cache if applicable). Does the issue persist?
- Check Monit, are you seeing high swap usage? Is Monit sending a lot of warnings about high memory usage and constantly restarting services? If either of these is true, then you probably need more RAM.
- Making sure you don’t have too many or too few workers is important. Assuming that’s the case and you’re following the 3-4 workers per vCPU guideline, check your PHP FPM log in your server customizer – are you seeing warnings like this?
[03-Dec-2021 01:59:02] WARNING: [pool examplewebsite.com74] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 16 children, there are 0 idle, and 5 total childrenIf yes, you likely need additional CPUs to cope with the current workload. See the above articles for more details.
PHP Memory vs WordPress Memory and how they impact performance
WP_MEMORY_LIMIT is the memory limit WordPress sets at runtime for any given request. For practical purposes, you really only need to focus on your PHP INI settings within your GP dashboard. Our defaults are ideal. Allocating more memory may be necessary if your codebase has inefficiencies – sometimes this is just unavoidable depending on the site and client budget, but we’ve also seen sites that require 2GB of RAM just to save a page, and that’s some crazy shit.
If a site needs a ton of memory to operate, then PHP will potentially consume a ton of RAM, which could impact your overall performance by taking away RAM from other services that need it.
Your codebase is really what needs focusing on.
How to troubleshoot high CPU usage, and interpret htop and other command-line tools to say, “Okay, this site needs X, Y, or Z”This is more of a misunderstanding than anything else.
top can help you identify what service is using the most CPU (PHP, MySQL, Nginx), it can help you identify a specific site that’s responsible for CPU usage, and it can help you identify things like iowait and CPU steal, which can both cause performance issues. You could also find that say backups are running and consuming a lot of resources for short periods of time.
It’s a starting point to help narrow down the source of your issues, and from there troubleshoot accordingly.