PHP-FPM ’ondemand’ Process Manager VS ’dynamic’ | Webcore Community

/php_fpm_ondemand_process_manager_vs_dyn

  • How to enable #HTTP/2 support in #Apache

    Starting from Apache 2.4.27, the Apache MPM (Multi-Processing Module) prefork no longer supports HTTP/2.To fix this, select a different MPM: event or worker. We highly recommend you to use the event prefork.
    If you are using PHP, it is likely that PHP is integrated to Apache via the mod_php module, which requires the prefork MPM. If you switch out from preform MPM, you will need to use PHP as FastCGI. To switch to php-fpm, you can do as folllwing.

    https://http2.pro/doc/Apache#prefork-http2
    https://httpd.apache.org/docs/2.4/fr/howto/http2.html#mpm-config

    Sur debian stretch ça donne ça (si on avait activé mpm_prefork alors que mpm_event est bien celui proposé par défaut) :

    apt install php-fpm
    a2enmod proxy_fcgi setenvif
    a2enconf php7.0-fpm
    a2dismod php7.0
    a2dismod mpm_prefork
    a2enmod mpm_event
    service apache2 restart
    apt purge libapache2-mod-php

    #http2 #mpm_event #php-fpm

    • Dans la foulée, deux liens à propos de l’optimisation de #php-fpm :

      Apache2 and php fpm performance optimization — Step-by-step guide

      https://medium.com/@sbuckpesch/apache2-and-php-fpm-performance-optimization-step-by-step-guide-1bfecf161534

      If you consistently see a large number of idle workers, you may want to lower your MinSpareServers (for the prefork MPM) or MinSpareThreads (for the worker and event MPMs) setting so that you are not sustaining a higher number of processes or threads than necessary to process your rate of traffic. Maintaining more processes or threads than you actually need will unncessarily exhaust system resources.

      https://www.datadoghq.com/blog/monitoring-apache-web-server-performance

    • Toujours à propos de #php-fpm, et de l’intérêt de basculer le process manager de dynamic (valeur par défaut) vers autre ondemand ou static.

      Certaines personnes recommandent d’utiliser ondemand pour ne pas avoir de process php en idle quand il n’y a pas de trafic :

      Dans mon cas j’ai 10 processus qui tournent en permanence, même si aucun de mes sites n’est visité.

      https://www.guillaume-leduc.fr/une-autre-facon-dutiliser-php-fpm.html

      If you’re working on a high performance PHP setup, the ’ondemand’ PM may not be for you. In that case, it’s wise to pre-fork your PHP-FPM processes up to the maximum your server can handle. That way, all your processes are ready to serve your requests without needing to be spawned first. However, for 90% of the sites out there, the ondemand PHP-FPM configuration is better than either static or dynamic.

      https://community.webcore.cloud/tutorials/php_fpm_ondemand_process_manager_vs_dynamic

      Mais comme indiqué ci-dessus, ça n’est pas forcément mieux car le process manager va devoir spawner des process alors que des process en idle permettent une réaction plus rapide en cas de pic de trafic :

      Idle process stay online waiting for traffic spikes and responding immediately, rather than having to wait on the pm to spawn children and then kill them off after x pm.process_idle_timeout expires...

      The common advice is to use pm ondemand, as is the advice in this same support thread. However, that’s even worse, because ondemand will shutdown idle processes right down to 0 when there’s little to no traffic and then you’ll end up with just as much overhead issues as traffic fluctuates.

      https://haydenjames.io/php-fpm-tuning-using-pm-static-max-performance

      Mais...

      PM dynamic and especially ondemand can be save you however, when you have multiple PHP-FPM pools. For example, hosting multiple cPanel accounts or multiple websites under different pools. I have a server for example with 100+ cpanel accounts and about 200+ domains and it would be impossible for pm.static or even dynamic to perform well. Only ondemand performs well since more than two third’s of the websites receive little to no traffic and with ondemand it means all children will be shutdown saving tons of server memory!

      When it comes to PHP-FPM, once you start to serve serious traffic, ondemand and dynamic process managers for PHP-FPM can limit throughput because of the inherent overhead. Know your system and set your PHP-FPM processes to match your server’s max capacity. Start with pm.max_children set based on max usage of pm dynamic or ondemand and then increase to the point where memory and CPU can process without becoming overwhelmed. You will notice that with pm static, because you keep everything sitting in memory, traffic spikes over time cause less spikes to CPU and your server’s load and CPU averages will be smoother. The average size of your PHP-FPM process will vary per web server requiring manual tuning, thus why the more automated overhead process managers – dynamic and ondemand – are more popular recommendations.

      Grosso merdo, il semble que dynamic peut faire le job quand on ne veut pas trop se prendre la tête, ondemand quand on sait à quoi s’attendre et qu’on est juste en mémoire (ou pour du dev), et static quand on veut faire du tuning précis.

      Un bon résumé :

      In dynamic type, the number of child processes is set dynamically based on the PHP-FPM parameters in conf file. But it is a bit memory-intensive type.

      In static type, the number of child processes is fixed by pm.max_children parameter, but this type is not flexible for a server with changing web traffic. It also consumes too much memory.

      In ondemand type, the PHP-FPM processes are spawned only on demand, based on the traffic. This type helps to manage varying traffic in memory restrained servers. But the overhead increases when there is so much traffic fluctuation.

      https://bobcares.com/blog/php-fpm-tuning-high-load

      Bref, comme souvent il n’y a pas de recette unique/magique :p

      Et vous les gens, vous utilisez quoi ?