Les drapeaux de réécriture - Serveur HTTP Apache Version 2.4
▻https://httpd.apache.org/docs/2.4/rewrite/flags.html
documentation des flags des RewriteRule d’apache
Les drapeaux de réécriture - Serveur HTTP Apache Version 2.4
▻https://httpd.apache.org/docs/2.4/rewrite/flags.html
documentation des flags des RewriteRule d’apache
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
a2enmod http2
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 ?
merci pour la sélection :)
Sur la question ThreadPerChild vs ServerLimit : ▻https://www.liquidweb.com/kb/apache-performance-tuning-mpm-directives
La doc apache : ▻http://httpd.apache.org/docs/2.4/mod/mpm_common.html#threadsperchild et ▻http://httpd.apache.org/docs/current/mod/mpm_common.html#maxrequestworkers
(NB : ThreadPerChild ne peut être supérieur à ThreadLimit)
Pour la configuration de Munin spécifique FPM + logs des requêtes lentes : ▻https://www.malekal.com/optimiser-php-fpm
https://community.webcore.cloud/tutorials/how_to_solve_php_fpm_server_reached_max_children
pour le calcul du max_children
#max_children
Et si on obtient l’erreur [proxy_fcgi:error] The timeout specified has expired
ça n’est pas sur la conf PHP max_execution_time
qu’il faut jouer, mais sur ProxyTimeout
au niveau de la conf apache cf ▻http://wiki.centos-webpanel.com/apache-proxy-timeout-with-php-fpm & ▻https://www.theshell.guru/proxy_fcgierror-the-timeout-specified-has-expired-apache-2-4
pour regrouper tous les outils en rapport avec les optimisation de configuration d’un serveur apache + PHP FPM, il y a aussi ►https://seenthis.net/messages/955121
HTTP/2 n’est pas le futur. C’est le présent. | Blog Eleven Labs
▻https://blog.eleven-labs.com/fr/http2-nest-pas-le-futur-cest-le-present
Une introduction à HTTP/2
En complément : la doc de mod_http2 d’Apache : ▻https://httpd.apache.org/docs/2.4/mod/mod_http2.html
Nouveau serveur Debian 8
Debian GNU/Linux 7.1 -> Debian 8
apache : 2.2 -> 2.4
php : 5.4.4 -> 5.6.7
Mise à jour de la version 2.2 vers la version 2.4 - Serveur Apache HTTP Version 2.5
▻https://httpd.apache.org/docs/trunk/fr/upgrading.html
Ce document présente les changements de comportement du serveur qui peuvent nécessiter une modification de la configuration, et la manière d’utiliser la version 2.4 du serveur en parallèle avec la version 2.2. Pour tirer parti des nouvelles fonctionnalités de la version 2.4, reportez-vous au document « Nouvelles fonctionnalités ».