Varnish Cache is a web application accelerator also known as a caching HTTP reverse proxy. It can be installed in front of any server that speaks HTTP and can be configured to cache the contents. Varnish Cache is really, really fast. It typically speeds up delivery with a factor of 300 – 1000x, depending on your architecture.
Cloudways implement Varnish to their web technology stack along with other caching layers.
Varnish can be activated on your Cloudways server by clicking on the Servers link on top then click on your server name, select Manage Services form the Server Management menu on the left and activate Varnish from the MANAGE SERVICES panel on the right.
As you can see, from there you can also purge your server’s cache or disable the cache altogether.
Apart from that, though, you can also enable/disable the Varnish cache for each of your applications. Just select the Applications link from the top of your Cloudways panel then select your application from the list that appears, click the Application Settings on the left from the Application Management panel and enable/disable accordingly.
I have been using Cloudways Managed WordPress hosting for some time now and I am more than happy. One of the few issues that bug me sometimes is an error I get usually after I clear my application Varnish cache and visit a page on the frontend. It doesn’t happen very often but when it does, I would get this page on the browser:
A couple of page refreshes usually fix the issue but I wasn’t happy that this was happening in the first place and I wanted a resolution on this. Searching for a solution, I discovered that there were quite a few cases of users having the exact same problem but solution was vage at best and no official post was published by Cloudways, probably due to the fact that each user case was unique.
I decided to initiate a ticket through the Cloudayws chat support. After a few moments, an agent asked me to confirm my server IP and I was given a few things to try out that could potentially fix the issue. I decided to write this blog post while I was implementing a few of those changes so other users could potentially benefit from what I had done.
Excessive number of applications
The good thing about Cloudways is that you could install a number of applications on the same server. Of course, the higher the number of applications you install, the more strain you put on your server. You could potentially alleviate the Varnish error on your server by having a small number of applications.
Server Execution Limit and Memory Limit
From your Server Management panel, under the Settings & Packages on the BASIC tab, there are a couple of settings that could help. I was told that the Execution Limit setting could be set to 1200 and the Memory Limit setting to 512.
Execution Limit is the amount of time a request is allowed to run across the stack. Web servers set a time limit on how long a script can run. This is done to prevent the webserver from abuse. Since WordPress is made up of PHP scripts, each script has to run completely within the set time limit. On Cloudways this time limit is usually 60 seconds, and in most cases, this is more than enough time for a script to run. However, if a PHP script runs for longer than the set time limit, PHP cuts short the execution. It then returns the fatal error: maximum execution time exceeded message.
Memory Limit is the maximum amount of Memory in (MB) that a PHP request is allowed to allocate. That means that if multiple requests were to use more than your server’s memory, you could potentially run out of memory so it depends on your server’s resources and the number of applications currently running on your server. So if you were to modify this settings, remember to monitor performance if your server resources are minimal.
Disable WP-CRON on on all applications
A suggestion was made to disable WP-CRON on all applications to optimize memory consumption on the server. This is easy to do. Just open the wp-config.php file located on your WordPress installation root folder and add the following just before the
/* That's all, stop editing! Happy blogging. */ line:
Then, save the file and reupload it on the server. You can then easily add a manual CRON job to your application by following this article. Alternatively, you can create your own CRON job on an external website such as this one that allows you to create CRON jobs from minute-by-minute to once a year, for free.
Checking your cache plugin settings
In case you have another caching plugin install, there might be some settings that need to be tweaked. You can experiment with some settings so that there are no conflicting issues. For example, I use Autoptimize to minify my scripts so I have minification deactivated in the Breeze plugin.
Disable Varnish on php stack applications
It is not recommended from Cloudways to have Varnish activated on custom PHP applications. You can easily disable it from your Application Settings console (see screenshot above).
Attacks on your login page
Usually malicious users or bots might be targeting your login pages and as a result, your server resources would be consumed and produce the 503 error. You could make use of your security plugin to apply a reCAPTCHA for all your login and registration page and also change your default login URL. For example, Wordfence has a function to enable reCAPTCHA on the login and user registration pages by going to Wordfence->Login Security, select the Settings tab and activate the Enable reCAPTCHA on the login and user registration pages checkbox. Various other security plugins can also do the job.
Attacks from WordPress XML-RPC
XML-RPC is a method that WordPress uses to communicate with external services and transmit data. With the introduction of the upcoming WordPress API we can expect XML-RPC to be eliminated entirely. Attackers could use brute force attacks through xmlrpc.php to gain access to your site. Hackers could also use the pingback feature in WordPress to send pingbacks to thousands of sites instantaneously. This feature in xmlrpc.php gives hackers a nearly endless supply of IP addresses to distribute a DDoS attack over. Those attacks could be easily overloading your server thus causing the 503 error.
You can use the XML-RPC Validator to examine if your site has XML-RPC running. If the test fails that means that XML-RPC is deactivated. To deactivate it you can make use of the Disable XML-RPC plugin or manually by adding the following to your .htaccess file:
# Block WordPress xmlrpc.php requests <Files xmlrpc.php> order deny,allow deny from all allow from 127.0.0.1 </Files>
Some security plugins like Wordfence also have the functionality to deactivate XML-RPC, built-in. Just head to WordFence->Login Security, select the Settings tab and enable the Disable XML-RPC authentication checkbox.
The application motoring tool on the Cloudways console can be used to monitor incoming traffic to your website. From there, you can check which IP requests and URLs accessing your site. You can find them by going to Applications->Application management -> Monitoring -> Analytics -> Traffic.
And there you have it!
Please, bear in mind that the above settings are not guaranteed to fix the issue and I suggest you try any changes on a cloned server beforehand. There is some useful info here for sure, though, and it would be interesting to see if any of these work for you.
You can visit the Cloudways Managed Cloud Hosting Platform and see if they have any plans that interest you. If you liked the article and thinking of signing up with Cloudways managed hosting, you can click on my affiliate link and signup.