error 502 on whm/cpanel for WordPress explained and solutions
Error 502 can be a drama – you’ve most likely found it through reports from jetpack, uptime robot or similar.
It comes and it goes – by the time you’ve logged the error – it’s gone, and your support guys say everything is fine.
Here is what causes error 502
- the default configuration of most web software is poor
- a slight change in pattern of server usage and you exhaust resources
- there is an escalation of resources requests, and the server gets busy this escalation escalates even more, yes – it’s circular
- instead of a gradual decline in response you get error 502 which means your web server is out of resources
Changing Hosts wont help you
If you take the same plan, some design, same idea, to a new host – you’ll get a similar result.
The fault of a web server ‘feels’ like it’s a hosting problem. But if you have a VPS, it’s largely your responsibility to fix. Even if it is a ‘managed VPS’ – see comments below on my ‘pet peeve’.
What causes it in more detail.
Your web server (most often apache), takes a ‘web hit’. The web server needs lots of ‘slots’ to accommodate lots of web hits from lots of users (1 slot per live/concurrent web hit).
Now if the web hit is a simple image or js, it can be served easily.
If it’s a WordPress page/post the webserver needs to fire up a php process, which is slow – and requests resources.
The first thing WordPress does is connect to the database, this requests more resources.
In general, this ‘requesting resources’ works fine. If the php executes quickly, it can release the database resources, and calculate the page, and release the php resources as well. And the resources can be used for the next hit. If the requests are at a reasonably constant pace – then there is enough resources available, and all is good.
But when the server slows a little (other users, or backups), or your web hits increase a little (even from crawl bots, like google/bingbot/baidu spider) more resources are requested, the requests take longer, there is more in flight at the same time, and then they take longer again.
The additional ‘in flight’ requests, go from normal 1-2, and can be as high as 100 or more. This means you’ve requested resources for:
- 100 web server / apache slots (these generally aren’t a problem – but if you server is super poorly configured they can be).
- 100 php sessions
- 100 mysql sessions
As the requests start to take longer, 1 of a few things happen
- if it’s your own poorly configured VPS, there may be no hard limits on resources, everything is consumed and you drop into a situation of ‘memory swapping to disk’. This swapping spiral can last quite a while. More requests taker longer, some return error 502.
- if your on a host with hard limits (like cloud linux), the server starts to kill off extra resources – which is what the error 502 are.
- If something starts to kill php sessions (from either scenarios above) the mysql resources aren’t properly released. This causes more error 502.
My pet peeve – managed hosting that is managed by exception
- they only do things when you ask
- they don’t configure your server to best practice – it’s configured just good enough
- you need to ask them to change the config – but most VPS owners dont know what to ask
- you deal with a support person that has technical ability – just a bit more than you
- no one is really engineering a good solution for you, or reviewing best practice
- sloppy poor configuration, error 502, leads to upselling of bigger plans
The solution
- Instead of dynamic allocation, you need static allocation.
- a set number of php instances always running, resources allocated ahead of time
- database resources allocated to match php allocation
- there are no surprises of resources limiting ballooning or escalating
- You need a queuing system when there are lots of hits
- that some hits are dealt with swiftly
- if it’s a robot, give them a page from cache, even if it’s old and stale – they’ll be back tomorrow for a better page. A fast response to spiders/bots is what is needed
- if it’s a simple request, like image/js/css , process it in the web sever without more resources
- if it’s a real user process via PHP
- other requests go through to your php allocation
- When all customers/accounts have resources pre-allocated, you’ll get consistent performance
- for php 5.6 and especially php 7.0, there is an added bonus that the php is about 3 times faster at page generation if it is has a static allocation.
- static allocation for php can be fcgid under Cpanel/WHM easy apache 3, or php-fpm (not well supported by cpanel/WHM – but we have a cpanel plugin for our customers). You need to use static allocation, not dynamic.
By
Scott Farrell on May 27th, 2016 ,
