Les sites web à fort trafic nécessitent une configuration spécifique des services. Selon le service choisi, il existe des recommandations pour obtenir des performances élevées d’un serveur VPS.

Augmenter simplement les ressources n’est pas suffisant pour atteindre des performances élevées d’un serveur VPS ; il est également nécessaire de configurer les services.

Par défaut, les services ont des paramètres de base adaptés aux projets typiques avec un trafic faible à moyen.

Pour plus de clarté, nous définirons les critèresස

• Faible trafic du site web : jusqu’à 10 000 visites par mois (~300 par jour, 1 visite toutes les 5 minutes).
• Trafic moyen du site web : de 10 000 à 90 000 visites – prenons une moyenne de 50 000 par mois (~1 600 par jour, 1 visite par minute).
• Fort trafic du site web : 100 000 visites par mois et plus, soit à partir de 2 visites par minute et plus.

Analysons une configuration où nginx agit comme serveur web proxy et php-fpm (dans ce cas, php8.3-fpm) comme gestionnaire principal.

Nous avons utilisé un serveur VPS sous Linux Debian 12, avec 6 cœurs CPU, 8 Go de RAM et un SSD de 50 Go.

Nous optimiserons les performances spécifiquement pour php8.3-fpm. Avec la configuration par défaut, nous avons exécuté un script d’analyse de liens, et en quelques minutes, le taux de requêtes est passé de 9 par seconde à 5. Après 5 minutes supplémentaires, les performances sont tombées à 1,5 requête par seconde, et le service a commencé à s’étouffer, renvoyant bientôt une erreur Bad Gateway.

Cependant, la charge du serveur n’a pas augmenté de manière significative, et il restait suffisamment de ressources pour traiter les requêtes.

1. Nouveau fichier de configuration php-fpm

Créez un nouveau fichier de configuration dans /etc/php/8.3/fpm/pool.d/domain.conf.

Renommez l’ancien fichier en www.conf.bak – cela garantit qu’il ne sera pas utilisé, mais vous pourrez y revenir en supprimant le suffixe .bak si nécessaire.

2. Détails de la configuration

[www]
user = www-data
group = www-data
listen = 127.0.0.1:9000
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

; Process manager
pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 500
pm.max_spawn_rate = 32
pm.process_idle_timeout = 10s

; Connection settings
listen.backlog = 65535
listen.allowed_clients = 127.0.0.1

; Timeouts
request_terminate_timeout = 30s
request_slowlog_timeout = 5s
slowlog = /var/log/php8.3-fpm/slow.log

; Status monitoring
pm.status_path = /fpm-status
ping.path = /ping
ping.response = pong

; Logging
access.log = /var/log/php8.3-fpm/access.log
access.format = "%R - %u %t \"%m %r%Q%q\" %s %f %{milli}dms"
catch_workers_output = yes
decorate_workers_output = no

; Security
security.limit_extensions = .php .php3 .php4 .php5 .php7 .php8
clear_env = no

; Performance tweaks
rlimit_files = 65535
rlimit_core = unlimited

; PHP settings
php_admin_value[error_log] = /var/log/php8.3-fpm/error.log
php_admin_flag[log_errors] = on
php_admin_value[memory_limit] = 128M
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 32M
php_admin_value[max_execution_time] = 30
php_admin_value[session.gc_maxlifetime] = 1440

3. Paramètres supplémentaires

Si le répertoire des journaux n’existe pas, créez-le :

mkdir -p /var/log/php8.3-fpm

3.1 Commentaires sur la configuration

• listen = 127.0.0.1:9000 - Doit correspondre à la configuration de nginx ou vice versa.
• pm.max_children = 50 - Dépend de la RAM disponible (50 Mo par processus enfant → ~2 Go pour PHP).
• pm.start_servers = 10 - ~20 % de pm.max_children.
• pm.max_requests = 500 - Redémarre les workers après 500 requêtes pour éviter les fuites de mémoire (imperceptible pour les visiteurs et n’affecte pas le fonctionnement).
• request_terminate_timeout = 30s - Termine les requêtes bloquées.
• request_slowlog_timeout = 5s - Enregistre les requêtes lentes.
• slowlog = /var/log/php8.3-fpm/slow.log

Le journal des requêtes lentes peut ne pas être très utile pour les sites basés sur des CMS, car il affichera une pile d’appels, mais il peut fournir des informations utiles sur l’intervalle de temps entre le début et la fin des requêtes.

Pour surveiller /fpm-status, ajoutez ce qui suit au bloc serveur de nginx :

    location = /fpm-status {
        allow 127.0.0.1;    # Autoriser uniquement l’accès local
        allow 192.168.10.100; # Ou votre réseau de confiance
        deny all;          # Refuser l’accès à tous les autres

        include /etc/nginx/fastcgi_params;
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_param SCRIPT_FILENAME $request_filename;
    }

La sortie aura le contenu suivant :

pool:                 www
process manager:      dynamic
start time:           04/Jun/2025:18:16:50 +0000
start since:          814
accepted conn:        239
listen queue:         0
max listen queue:     0
listen queue len:     128
idle processes:       9
active processes:     1
total processes:      10
max active processes: 3
max children reached: 0
slow requests:        0

4. Appliquer la nouvelle configuration

Vérifiez le fichier de configuration pour détecter les erreurs :

php-fpm8.3 -t

S’il n’y a pas d’erreurs, redémarrez le service :

systemctl restart php8.3-fpm

5. Nouveau test

Avec la nouvelle configuration, la charge du CPU a augmenté de manière notable lors de tests similaires, mais les performances n’ont diminué que de 20 % (de 9 requêtes par seconde à 7) après quelques minutes et se sont stabilisées. Toutes les requêtes (~10 000 sur 25 minutes, soit 400 requêtes par minute ou ~7 par seconde) ont été traitées avec succès avec un code de statut 200.

Visuellement, la navigation sur le site pendant des tests simultanés a montré des performances nettement plus rapides. Avec cette configuration des services web, les ressources du serveur sont désormais pleinement utilisées, au lieu de rester inactives comme auparavant.