Understanding how a PHP processes work is essential when trying to maximize the delivering of data to a customer. A common misconception is a belief that increasing the RAM value per process equates to superior performance. Many Open Source applications require a minimum amount of Memory to work efficiently; this value agreed upon after extensive testing by the development team. As with all extensible applications when they become more feature-rich because the customer requirements change, we think inherently slower or no response times means the solution is adding more RAM to each PHP process, or so it seems.
Increasing the PHP memory limit is not a good companion. It should never be the first port of call when you see an application running slow, and never use the setting below as it has the potential to create an enormous amount of frustration in the future. The use of -1 allocates all available PHP RAM if needed by the application to that single process request.
ini_set('memory_limit',-1); //-- Please don't
Increasing the maximum allocated PHP RAM will not necessarily increase page load times, and fix slow responses that seem to be caused by a PHP process that does not have enough RAM to complete a task. The premise of increasing RAM to solve the response time sounds like a feasible solution. However, before you take that decision, you need to look at some other variations that could be the cause. To illustrate how a development team can to the point they allocate the entire PHP pool to one process consider the following,
The team are getting reports of a website that only needs a minimum requirement of 128MB of PHP memory to run effectively, but it has slow request times, and the changes the team have made are small. It must be PHP, the team starts increasing the amount of PHP memory to negate the slowness issue until you have one PHP request that is unconstrained and may consume the entire PHP memory allocation needed.
The above example when the server gets put under load with many PHP requests will eventually bring the website to a grinding halt, without knowing it, the team has built in a point of failure. This issue can be resolved by understanding that the lack of PHP ram is not always the underlying issue to an application running slow, which could be one of the several items listed below.
- The number of processes your webserver is requesting PHP to be completed
- External calls to third-party services when under load work negatively
- CRONs that are requesting PHP processes in an excessive amount
- Maximum Memory allocation halting the amount of process that can be requested
All servers have physical constraints; they don't have an endless amount of physical RAM that can be used by software services that have been augmented by an administration layer. So restrictions need to be enforced, and an assignment of resources is imposed this includes the PHP software service (Yes, it's a software program).
All developers need to remember a PHP process only needs enough PHP memory to execute the PHP code with a minimum amount of resources.
Instead, when a developer decides to increase the PHP memory so that a single process is allowed to access a large amount of the Memory will fail when continuous consignments of requests are assigned to be completed. The failure is due to the server not be able to spawn concurrent PHP processes as there is not enough memory, which will display the server has insufficient resources for the sites' requirements. The problem that has been created is commonly referred to as skip-spawning or request queueing.
When a web server gets a request, it passes it to the PHP service and when there are no available PHP processes to handle it. The result is the requests get queued, which means that pages may be slow to load or eventually time out, resulting in a "Temporarily Unavailable" error on the site and "HTTP 503" errors in your request logs. This type of error can have several underlying issues developers or DevOps need to check before exploring increasing the Memory limit for each PHP request.
What can cause a website to run slow or not send data? Below I have compiled the main impediments that encourage someone to inflate Memory when it might not be needed.
- Turn on caching, which offloads complete PHP requests and database calls.
- Optimize code, removal of things like warnings and all other errors.
- Reduce the amount of data loading on a page to allow page requests to complete faster, reducing the likelihood of requests backing up.
- Give external calls the ability to time out using libraries like Guzzle can help
- If your application uses MySQL, adding Memcache to reduce database queries
- Install APC Opcache to cache the PHP queries
- Place Varnish in front of the Web server
- Use a CDN to distribute the static images and access
Finally, you can upsize your server(s) add additional Memory to so the system can supplement to the current PHP memory pool giving the PHP service greater access to other PHP processes. When considering adjusting the memory limit to accommodate the websites memory needs with the number of concurrent connections, the DevOps or Development team need to understand how PHP memory works.
It's essential to balance the needs of your PHP applications use of memory with the number of available concurrent PHP connections processes that can be used.
Each server (instance) size has a fixed amount of Memory which is configured with memory allocation for all the things required to run your website, e.g. the Operating System. PHP then gets a fixed assignment of Memory that is a hardcoded value, PHP memory is broken down into different segments,
- The first assigned to the APC Opcache this value is a fix set amount, and APC and Opcache are segmented as well.
- The remaining PHP memory is then divided by using the value set in the PHP memory_limit to give the number of available PHP processes for the site.
So if you raise the PHP memory_limit, you, reduce the number of concurrent PHP processes available at any given, if the website comes under load and the memory allocation is too large, then it will adversely affect your application and harm the performance of your website. How do you troubleshoot this issue? The solution is simple, search your fpm-access logs for the following string,
"server reached max_children setting"
The PHP application service was created so that a voluminous amount of requests can execute a developers PHP code at any one time and return positive, robust results in a reliable fashion, but if miss managed it can be you worst enemy; and adversely affect your application work optimally.