• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Question FTM or FastCGI for a website with a lot of session

Erwan

Regular Pleskian
Hi all,

We have problem with one server which can have peaks in visits at times.
Process go to 100%.
PHP works with FPM / Apache.

After various tests, the best configuration of the PHP we could obtain is:
pm.max_children = 450
pm = static

But when there are really too many visitors, the server does not resist.

We are seeing to put two web frontends. My question is: what is the best way to configure the PHP mode to serve the maximum number of customers in a reasonable time?
FPM / Apache
FastCGI / Apache
NB: we can use FPM/Nginx because there is htaccess and i believe it can't work in this case.

For me FPM/Apache is better but how to handle pm.max_children constraints?
We replace the server with an equivalent with 2x more RAM (128G), is that a plus for this parameter? how to optimize it?
All this to avoid to block all the visits as we reach a certain number of visitors.

Thank you for your help.
 
450 children sounds too many for me.

Apache itself can handle a maximum of 255 sessions, however, it will be awfully slow even on very powerful servers when the max is reached. Probably Apache will become unresponsive. A realistic number of Apache instances is somewhere around 120 for a 12 core system. Rule of thumb: Per processor core calculate 10 Apache web server instances.

While an Apache instance can service several PHP requests, things normally get tough when the number of PHP instances reaches the number of Apache instances. This will normally lead to an unresponsive system, too. With a very high number of PHP-FPM children you are guaranteed to create stalls on PHP or Apache. This happens not for "normal" PHP script interpretation, because normally a PHP instance should complete within a few milliseconds. However, if the software is not well written and one instance is waiting in infinite loops or waiting on external input or running unnecessarily long for other reasons, more and more FPM instances need to be created to service new incoming requests. But all these additional requests block another instance, because once again the script does not finish.

How much RAM does a single instance of PHP-FPM need on your server? How much RAM does the script require that requires most RAM? Can the number of requests be handled by your system?

Suggestions:

a) Do not use "static", because with "static" blocks resources on your system for good. Use "on demand" instead. This enables your server to kill PHP-FPM instances once they are done with their job, so that resources can be freed.
b) Limit pm.max_children to no more than rule-of-thumb 10 times your processor cores. On many systems this will be too much, so better a bit less. When the max_children limit is reached, new requests from users will not be responded to. This is by design, but it is important to protect your server from too much load.
c) Analyze why your scripts are running so very long that PHP-FPM instances don't end their work, but continue to create cpu load. Correct the scripts so that they do not end up in infinite loops.
d) Limit the max runtime of your scripts (by PHP setting) to a low number. Many users love long max runtime settings, but actually it is important to enforce short script run times to free resources for run-away processes. For almost all normally working scripts run times of a few seconds are sufficient. If you have it set to 20 seconds you are already "very long" with you run time.
e) Limit the number of pm.max_requests to a few thousand, so that each child stops after processing that number of requests and frees its resources. Else you run the risk to crash the server due to memory leaks or other unexpected things.
f) One major cause for overload situations are attacks. Carefully analyze your log files where your requests are coming from. Use Fail2Ban to restrict access.
g) Use DNS round robin to distribute requests against your website to many servers.
 
Back
Top