11. Durcissement et optimisation de la pile LEMP

11.1. Introduction au durcissement et à l’optimisation

Après avoir installé la pile LEMP, il est essentiel de durcir et d’optimiser chaque composant pour garantir une sécurité et des performances maximales. Cette section couvre les configurations avancées pour Nginx, MariaDB et PHP-FPM qui permettront de :

1. Améliorer la sécurité en réduisant les surfaces d’attaque
2. Améliorer les performances pour gérer le trafic WordPress
3. Optimiser l’utilisation des ressources sur votre serveur
4. Préparer votre serveur pour les charges de travail de production

Avantages de performance

Des serveurs web correctement optimisés peuvent gérer significativement plus de trafic avec les mêmes ressources matérielles. Ces optimisations peuvent améliorer les temps de chargement des pages de 30 à 50 % et augmenter le nombre d’utilisateurs simultanés que votre serveur peut gérer.

11.2. Optimisation de la configuration Nginx

Nginx est hautement configurable et peut être affiné pour de meilleures performances et une meilleure sécurité. Nous allons organiser notre configuration en fichiers modulaires pour une gestion plus facile.

11.2.1. Préparation

Commençons par créer une sauvegarde de la configuration d’origine et mettre en place une structure de répertoires pour nos fichiers de configuration modulaires :

# Naviguer vers le répertoire de configuration Nginx
cd /etc/nginx/

# Créer un répertoire includes pour la configuration modulaire
sudo mkdir includes/

# Créer une sauvegarde de la configuration d'origine
sudo cp nginx.conf nginx.conf.bak

# Modifier le fichier de configuration principal
sudo vim nginx.conf

11.2.2. Optimisation du contexte principal

Ajoutez les directives suivantes au contexte principal (en dehors de tout bloc) dans votre fichier nginx.conf :

# Augmenter le nombre maximum de fichiers ouverts par worker
worker_rlimit_nofile 30000;

# Définir la priorité des processus worker (-20 à 19, plus bas = plus haute priorité)
worker_priority -10;

# Optimiser la résolution du minuteur interne
timer_resolution 100ms;

# Activer la compilation JIT PCRE pour de meilleures performances regex
pcre_jit on;

Ces paramètres :

• Augmentent la limite des descripteurs de fichiers pour les workers Nginx
• Donnent aux workers Nginx une priorité CPU plus élevée
• Optimisent la résolution du minuteur pour de meilleures performances
• Activent la compilation Just-In-Time pour les expressions régulières

11.2.3. Optimisation du contexte Events

Dans le bloc events {}, modifiez ou ajoutez ces directives :

events {
    # Augmenter le maximum de connexions par worker
    worker_connections 4096;

    # Activer l'accept mutex pour une meilleure distribution des connexions
    accept_mutex on;

    # Définir le délai de l'accept mutex
    accept_mutex_delay 200ms;

    # Utiliser le modèle d'événements epoll efficace sous Linux
    use epoll;
}

Ces paramètres optimisent la gestion des connexions par Nginx :

• Augmentent le nombre de connexions simultanées que chaque worker peut gérer
• Améliorent la distribution des connexions entre les processus worker
• Utilisent la méthode de traitement d’événements epoll efficace disponible sous Linux

11.2.4. Création de fichiers de configuration modulaires

Créons des fichiers de configuration séparés pour les différents aspects de Nginx :

# Naviguer vers le répertoire includes
cd /etc/nginx/includes/

# Créer les fichiers de configuration pour les différents aspects
sudo touch basic_settings.conf buffers.conf timeouts.conf file_handle_cache.conf gzip.conf brotli.conf

# Lister les fichiers pour confirmer la création
ls -l

11.2.5. Configuration des paramètres de base

Créez le fichier de configuration des paramètres de base :

# Modifier la configuration des paramètres de base
sudo vim /etc/nginx/includes/basic_settings.conf

Ajoutez le contenu suivant :

##
# PARAMETRES DE BASE
##
# Définir l'encodage des caractères
charset utf-8;

# Activer la distribution efficace des fichiers
sendfile on;
sendfile_max_chunk 512k;

# Optimiser les paramètres TCP
tcp_nopush on;
tcp_nodelay on;

# Sécurité : Masquer les informations du serveur
server_tokens off;
more_clear_headers 'Server';
more_clear_headers 'X-Powered';

# Gestion des noms de serveur
server_name_in_redirect off;
server_names_hash_bucket_size 64;

# Paramètres des tables de hachage
variables_hash_max_size 2048;
types_hash_max_size 2048;

# Types MIME
include /etc/nginx/mime.types;
default_type application/octet-stream;

Ces paramètres :

• Définissent UTF-8 comme encodage de caractères par défaut
• Activent la distribution efficace des fichiers avec sendfile
• Optimisent TCP pour de meilleures performances
• Masquent les informations du serveur pour une meilleure sécurité
• Configurent les tables de hachage pour de meilleures performances

11.2.6. Configuration des tampons

Créez le fichier de configuration des tampons :

# Modifier la configuration des tampons
sudo vim /etc/nginx/includes/buffers.conf

Ajoutez le contenu suivant :

##
# TAMPONS
##
# Tampons pour les requêtes client
client_body_buffer_size 256k;
client_body_in_file_only off;
client_header_buffer_size 64k;
client_max_body_size 100m; # Envisagez de réduire après la configuration


# Tampons de connexion et d'E/S
connection_pool_size 512;
directio 4m;
ignore_invalid_headers on;
large_client_header_buffers 8 64k;
output_buffers 8 256k;
postpone_output 1460;
request_pool_size 32k;

Ces paramètres de tampons :

• Optimisent l’utilisation de la mémoire pour les requêtes client
• Définissent des tailles de tampons appropriées pour les en-têtes et le contenu du corps
• Configurent les opérations d’E/S pour de meilleures performances
• Définissent une taille maximale raisonnable du corps pour les téléchargements de fichiers

11.2.7. Configuration des délais d’attente

Créez le fichier de configuration des délais d’attente :

# Modifier la configuration des délais d'attente
sudo vim /etc/nginx/includes/timeouts.conf

Ajoutez le contenu suivant :

##
# DELAIS D'ATTENTE
##
# Délais de connexion
keepalive_timeout 5;
keepalive_requests 500;
lingering_time 20s;
lingering_timeout 5s;
keepalive_disable msie6;

# Réinitialiser les connexions expirées
reset_timedout_connection on;

# Délais de requête
send_timeout 15s;
client_header_timeout 8s;
client_body_timeout 10s;

Ces paramètres de délais d’attente :

• Optimisent la gestion des connexions et l’utilisation des ressources
• Empêchent les clients lents de consommer les ressources du serveur
• Ferment les connexions inactives après 5 secondes
• Autorisent jusqu’à 500 requêtes par connexion avant la fermeture

11.2.8. Paramètres de compression

Configuration Gzip

Créez le fichier de configuration de compression Gzip :

# Modifier la configuration gzip
sudo vim /etc/nginx/includes/gzip.conf

Ajoutez le contenu suivant :

##
# GZIP
##
# Activer la compression gzip
gzip on;
gzip_vary on;
gzip_disable "MSIE [1-6]\.";
gzip_static on;

# Paramètres gzip
gzip_min_length 1400;
gzip_buffers 32 8k;
gzip_http_version 1.0;
gzip_comp_level 5;
gzip_proxied any;

# Types MIME à compresser
gzip_types text/plain text/css text/xml application/javascript application/x-javascript
           application/xml application/xml+rss application/ecmascript application/json
           image/svg+xml;

Configuration Brotli

Créez le fichier de configuration de compression Brotli :

# Modifier la configuration brotli
sudo vim /etc/nginx/includes/brotli.conf

Ajoutez le contenu suivant :

##
# BROTLI
##
# Activer la compression Brotli
brotli on;
brotli_comp_level 6;
brotli_static on;

# Types MIME à compresser avec Brotli
brotli_types application/atom+xml application/javascript application/json application/rss+xml
            application/vnd.ms-fontobject application/x-font-opentype application/x-font-truetype
            application/x-font-ttf application/x-javascript application/xhtml+xml application/xml
            font/eot font/opentype font/otf font/truetype image/svg+xml image/vnd.microsoft.icon
            image/x-icon image/x-win-bitmap text/css text/javascript text/plain text/xml;

Avantages de la compression :

• Réduit l’utilisation de la bande passante de 70 à 90 % pour le contenu textuel
• Améliore les temps de chargement des pages pour les visiteurs
• Brotli obtient généralement une compression 15 à 25 % meilleure que Gzip

11.2.9. Configuration du cache des descripteurs de fichiers

Créez le fichier de configuration du cache des descripteurs de fichiers :

# Modifier la configuration du cache des descripteurs de fichiers
sudo vim /etc/nginx/includes/file_handle_cache.conf

Ajoutez le contenu suivant :

##
# CACHE DES DESCRIPTEURS DE FICHIERS
##
# Mettre en cache les descripteurs de fichiers ouverts et les informations
open_file_cache max=50000 inactive=60s;
open_file_cache_valid 120s;
open_file_cache_min_uses 2;
open_file_cache_errors off;

Ces paramètres :

• Mettent en cache les informations sur les fichiers ouverts pour réduire les E/S disque
• Stockent jusqu’à 50 000 entrées de fichiers dans le cache
• Suppriment les entrées non accédées pendant 60 secondes
• Valident les entrées du cache toutes les 120 secondes
• Nécessitent au moins 2 utilisations avant de mettre un fichier en cache

11.2.10. Intégration des fichiers de configuration dans Nginx

Maintenant que nous avons créé tous nos fichiers de configuration modulaires, nous devons les intégrer dans le fichier de configuration principal de Nginx.

Commençons par modifier le fichier de configuration principal :

# Modifier le fichier de configuration principal de Nginx
sudo vim /etc/nginx/nginx.conf

Suppression des blocs de configuration par défaut

Dans le bloc http {} de votre fichier nginx.conf, vous devrez supprimer ou commenter les sections par défaut suivantes :

##
# Basic Settings
##

##
# SSL Settings
##

##
# Logging Settings
##

##
# Gzip Settings
##

Ajout des directives d’inclusion

Remplacez les sections supprimées par des directives d’inclusion vers nos fichiers de configuration modulaires. Votre bloc http {} devrait ressembler à ceci :

http {
    # Paramètres de base
    include /etc/nginx/includes/basic_settings.conf;

    # Paramètres de tampons
    include /etc/nginx/includes/buffers.conf;

    # Paramètres de délais d'attente
    include /etc/nginx/includes/timeouts.conf;

    # Paramètres du cache des descripteurs de fichiers
    include /etc/nginx/includes/file_handle_cache.conf;

    # Paramètres SSL
    # (Conserver les paramètres SSL existants ici)

    # Paramètres de journalisation
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    # Paramètres de compression
    include /etc/nginx/includes/gzip.conf;
    include /etc/nginx/includes/brotli.conf;

    # Configurations des hôtes virtuels
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

Cette approche modulaire rend votre configuration :

• Plus facile à maintenir et à mettre à jour
• Plus organisée et lisible
• Plus simple à dépanner en cas de problème

11.2.11. Test et application de la configuration

Après avoir effectué toutes les modifications, il est essentiel de tester la configuration avant de l’appliquer :

# Tester la configuration Nginx pour les erreurs de syntaxe
sudo nginx -t

Si le test est réussi, rechargez Nginx pour appliquer les modifications :

# Recharger Nginx avec la nouvelle configuration
sudo systemctl reload nginx

11.2.12. Vérification des limites de descripteurs de fichiers

Pour s’assurer que nos paramètres de limite de descripteurs de fichiers sont correctement appliqués :

# Trouver les processus worker Nginx
ps aux | grep nginx

# Vérifier les limites de descripteurs de fichiers pour un processus worker
# Remplacez XXXX par le PID réel de la commande précédente
sudo cat /proc/XXXX/limits | grep "open files"

Si vous devez augmenter davantage la limite des descripteurs de fichiers, vous pouvez modifier la directive worker_rlimit_nofile dans le contexte principal de nginx.conf :

# Modifier nginx.conf à nouveau si nécessaire
sudo vim /etc/nginx/nginx.conf

Augmentez la valeur si nécessaire :

# Augmenter la limite des descripteurs de fichiers si nécessaire
worker_rlimit_nofile 45000;

Après toute modification, testez et rechargez Nginx à nouveau :

# Tester la configuration
sudo nginx -t

# Recharger Nginx
sudo systemctl reload nginx

11.3. Création d’alias Bash utiles

Les alias Bash peuvent vous faire gagner du temps en créant des raccourcis pour les commandes fréquemment utilisées. C’est particulièrement utile lors de la gestion de votre serveur.

11.3.1. Mise en place des alias de gestion serveur

Créez ou modifiez votre fichier .bash_aliases :

# Modifier votre fichier d'alias bash
vim ~/.bash_aliases

Ajoutez les alias utiles suivants pour la gestion du serveur :

# Mise à jour et maintenance système
alias server_update='sudo apt update && sudo apt upgrade && sudo apt autoremove'

# Gestion Nginx
alias ngt='sudo nginx -t'                                # Tester la configuration Nginx
alias ngr='sudo systemctl reload nginx'                  # Recharger Nginx
alias ngsa='cd /etc/nginx/sites-available/ && ls'        # Naviguer vers sites-available
alias ngin='cd /etc/nginx/includes/ && ls'               # Naviguer vers le répertoire includes

# Gestion PHP-FPM
alias fpmr='sudo systemctl restart php8.3-fpm'           # Redémarrer PHP-FPM

11.3.2. Activation de vos alias

Pour rendre vos alias disponibles dans votre session actuelle :

# Sourcer votre fichier d'alias bash
source ~/.bash_aliases

Pour tester que vos alias fonctionnent :

# Tester la configuration nginx avec l'alias
ngt

Gain de temps

Ces alias peuvent réduire significativement la saisie et vous aider à gérer votre serveur plus efficacement. Vous pouvez ajouter d’autres alias pour d’autres tâches courantes au fur et à mesure que vous vous familiarisez avec votre flux de travail.

11.4. Optimisation et sécurisation de MariaDB

MariaDB est le serveur de base de données qui stocke toutes vos données WordPress. Sa configuration correcte est cruciale tant pour la sécurité que pour les performances.

11.4.1. Sécurisation de l’installation de MariaDB

Commencez par exécuter le script d’installation sécurisée de MariaDB pour supprimer les paramètres par défaut non sécurisés et verrouiller l’accès :

# Exécuter le script de sécurité
sudo mysql_secure_installation

11.4.2. Comprendre les options du script de sécurité

Lors de l’exécution du script mysql_secure_installation, plusieurs options de sécurité vous seront présentées. Voici ce que chaque option signifie et les paramètres recommandés :

1. Mot de passe root : Si c’est la première fois que vous exécutez le script, il vous sera demandé de définir un mot de passe root. Choisissez un mot de passe fort et conservez-le en lieu sûr.

2. Authentification par socket Unix : Cette option vous permet de vous authentifier en utilisant le fichier socket Unix au lieu d’un mot de passe. Pour la plupart des configurations WordPress, vous pouvez répondre n.

3. Changer le mot de passe root : Si vous avez déjà défini un mot de passe root, vous pouvez choisir de le changer ou de le conserver en répondant n.

4. Supprimer les utilisateurs anonymes : Les utilisateurs anonymes sont un risque de sécurité et doivent être supprimés en environnement de production. Répondez Y.

5. Interdire la connexion root à distance : Empêcher la connexion root à distance est une bonne pratique de sécurité. Répondez Y.

6. Supprimer la base de données de test : La base de données de test n’est pas nécessaire en production et doit être supprimée. Répondez Y.

7. Recharger les tables de privilèges : Cela applique immédiatement toutes les modifications. Répondez Y.

Bonnes pratiques de sécurité

Complétez toujours l’intégralité du processus mysql_secure_installation sur les serveurs de production. Ces mesures de sécurité aident à protéger votre base de données contre les vecteurs d’attaque courants.

11.4.3. Optimisation des performances de MariaDB

Après avoir sécurisé MariaDB, optimisons ses performances pour WordPress. Commencez par créer une sauvegarde du fichier de configuration :

# Naviguer vers le répertoire de configuration de MariaDB
cd /etc/mysql/mariadb.conf.d/

# Créer une sauvegarde de la configuration du serveur
sudo cp 50-server.cnf 50-server.cnf.bak

# Modifier le fichier de configuration
sudo vim 50-server.cnf

Activation du Performance Schema

Le Performance Schema fournit une instrumentation pour aider à surveiller l’exécution du serveur MariaDB à bas niveau. Ajoutez ces lignes à la section [mysqld] :

# Performance Schema
performance_schema=ON
performance-schema-instrument='stage/%=ON'
performance-schema-consumer-events-stages-current=ON
performance-schema-consumer-events-stages-history=ON
performance-schema-consumer-events-stages-history-long=ON

Désactivation des recherches DNS

Ajoutez cette ligne pour améliorer la vitesse de connexion en empêchant les recherches DNS :

# Désactiver les recherches DNS pour les connexions client
skip-name-resolve

Cela empêche le serveur de tenter de résoudre les noms d’hôte des clients, ce qui peut ralentir les connexions, en particulier lorsque le DNS est lent ou indisponible.

Configuration du cache de requêtes

MariaDB inclut une fonctionnalité de cache de requêtes qui peut améliorer les performances pour les charges de travail à forte lecture en mettant en cache les résultats des requêtes SELECT. Vous pouvez vérifier les paramètres actuels du cache de requêtes :

# Se connecter à MariaDB
sudo mysql -u root -p

# Vérifier si le cache de requêtes est disponible
MariaDB [(none)]> show variables like 'have_query_cache';

# Vérifier les paramètres du cache de requêtes
MariaDB [(none)]> show variables like 'query_cache%';

Pour les sites WordPress avec un trafic modéré, vous pouvez activer et configurer le cache de requêtes en ajoutant ces lignes à la section [mysqld] :

# Configuration du cache de requêtes
query_cache_type = 1
query_cache_size = 16M
query_cache_limit = 1M

Considérations sur le cache de requêtes

Bien que le cache de requêtes puisse améliorer les performances pour les sites avec plus de lectures que d’écritures, il peut en réalité diminuer les performances sur les sites à fort trafic avec des changements de données fréquents. Surveillez les performances de votre site et ajustez en conséquence.

Optimisation des journaux binaires

Les journaux binaires enregistrent toutes les modifications de votre base de données et sont utilisés pour la réplication et la récupération ponctuelle. Par défaut, ces journaux sont conservés pendant 10 jours, ce qui peut consommer un espace disque important. Vous pouvez vérifier et modifier la période de rétention :

# Vérifier le paramètre actuel d'expiration des journaux binaires
MariaDB [(none)]> show variables like 'expire_logs_days';

# Définir l'expiration des journaux binaires après 3 jours
MariaDB [(none)]> set global expire_logs_days = 3;

# Vérifier la modification
MariaDB [(none)]> show variables like 'expire_logs_days';

# Purger les journaux binaires pour appliquer les modifications
MariaDB [(none)]> flush binary logs;

Pour rendre cette modification permanente, ajoutez cette ligne à la section [mysqld] de votre configuration MariaDB :

# Paramètres des journaux binaires
expire_logs_days = 3

Optimisation du pool de tampons InnoDB

InnoDB est le moteur de stockage par défaut de MariaDB et est optimisé pour les performances et la fiabilité. Le pool de tampons est l’un des paramètres les plus importants à régler pour les performances :

# Vérifier les paramètres actuels du pool de tampons InnoDB
MariaDB [(none)]> show variables like '%innodb_buffer%';

# Vérifier les paramètres des fichiers journaux InnoDB
MariaDB [(none)]> show variables like '%innodb_log%';

Pour des performances optimales, ajoutez ces paramètres à la section [mysqld] de votre configuration MariaDB :

# Paramètres InnoDB
innodb_buffer_pool_size = 800M
innodb_log_file_size = 200M

Dimensionnement du pool de tampons

Le innodb_buffer_pool_size devrait être défini à environ 70-80 % de la RAM disponible pour les serveurs de base de données dédiés, ou 25-30 % pour les serveurs qui exécutent également le serveur web et d’autres services. Pour un serveur avec 4 Go de RAM exécutant la pile LEMP complète, 800 Mo à 1 Go est un bon point de départ.

Après avoir effectué ces modifications, redémarrez MariaDB pour les appliquer :

# Redémarrer MariaDB
sudo systemctl restart mariadb

Optimisation avancée InnoDB

Pour les serveurs plus importants avec plus de RAM, vous pouvez optimiser davantage InnoDB :

# Paramètres InnoDB avancés pour les serveurs avec 8 Go+ de RAM
innodb_buffer_pool_size = 2048M
innodb_log_file_size = 512M

Modification de la taille du fichier journal

Lors de la modification de innodb_log_file_size, vous devez arrêter complètement MariaDB avant d’effectuer la modification :

# Arrêter MariaDB
sudo systemctl stop mariadb

# Effectuer les modifications de configuration
sudo vim /etc/mysql/mariadb.conf.d/50-server.cnf

# Démarrer MariaDB
sudo systemctl start mariadb

Cela est nécessaire car les fichiers journaux doivent être recréés avec la nouvelle taille au démarrage du serveur.

11.4.4. Utilisation de MySQLTuner pour une optimisation avancée

MySQLTuner est un script Perl qui analyse les performances de votre MariaDB et fournit des recommandations pour les améliorer :

# Télécharger MySQLTuner
wget http://mysqltuner.pl/ -O mysqltuner.pl

# Le rendre exécutable
chmod +x mysqltuner.pl

# Exécuter MySQLTuner (meilleur après au moins 24 heures de fonctionnement du serveur)
sudo ./mysqltuner.pl

MySQLTuner analysera votre configuration et vos schémas d’utilisation actuels, puis fournira des recommandations spécifiques pour optimiser votre installation MariaDB. C’est particulièrement précieux après que votre site WordPress a fonctionné pendant un certain temps, car il peut identifier les goulots d’étranglement basés sur l’utilisation réelle.

11.4.5. Augmentation des limites de descripteurs de fichiers de MariaDB

MariaDB, comme d’autres services, est limitée par le nombre de fichiers ouverts qu’elle peut avoir. Pour les bases de données très sollicitées, les limites par défaut peuvent être trop basses :

# Vérifier les limites actuelles de descripteurs de fichiers pour MariaDB
ps aux | grep mysql
cat /proc/$(ps aux | grep mysql | grep -v grep | awk '{print $2}')/limits | grep "Max open files"

Pour augmenter les limites de descripteurs de fichiers pour MariaDB :

# Naviguer vers le répertoire systemd
cd /etc/systemd/system/

# Créer un répertoire pour les surcharges du service MariaDB s'il n'existe pas
sudo mkdir -p mariadb.service.d/

# Naviguer vers le nouveau répertoire
cd mariadb.service.d/

# Créer un fichier de configuration des limites
sudo nano limits.conf

Ajoutez le contenu suivant au fichier limits.conf :

[Service]
LimitNOFILE=40000

Appliquez les modifications :

# Recharger systemd pour reconnaître les modifications
sudo systemctl daemon-reload

# Redémarrer MariaDB
sudo systemctl restart mariadb

# Vérifier les nouvelles limites
cat /proc/$(ps aux | grep mysql | grep -v grep | awk '{print $2}')/limits | grep "Max open files"

Vous devriez voir que la valeur “Max open files” a été augmentée à 40000, ce qui permettra à MariaDB de gérer plus de connexions et d’opérations simultanées.

11.5. Durcissement et optimisation de PHP-FPM

PHP-FPM (FastCGI Process Manager) est l’implémentation PHP qui fonctionne avec Nginx. La configuration correcte de PHP-FPM est essentielle tant pour la sécurité que pour les performances.

11.5.1. Paramètres de sécurité et de performance PHP

Modifiez le fichier de configuration PHP :

# Trouver le fichier de configuration PHP principal
sudo find /etc/php/8.3/ -name php.ini

# Modifier le fichier de configuration PHP (ajustez le chemin si nécessaire)
sudo vim /etc/php/8.3/fpm/php.ini

Ajoutez ou modifiez les paramètres suivants :

; Paramètres de sécurité
allow_url_fopen = Off        ; Empêche PHP d'ouvrir des fichiers distants
cgi.fix_pathinfo = 0         ; Empêche les vulnérabilités de traversée de chemin
expose_php = Off             ; Masque la version de PHP dans les en-têtes HTTP

; Paramètres de performance
upload_max_filesize = 100M   ; Taille maximale autorisée pour les fichiers téléchargés
post_max_size = 125M         ; Taille maximale des données POST (devrait être supérieure à upload_max_filesize)
max_input_vars = 3000        ; Variables d'entrée maximum (important pour les formulaires WordPress complexes)
memory_limit = 256M          ; Mémoire maximale qu'un script peut consommer

; Limites de ressources
rlimit_files = 32768         ; Nombre maximum de fichiers ouverts
rlimit_core = unlimited      ; Autoriser les core dumps pour le débogage

11.5.2. Configuration du pool PHP-FPM

Pour de meilleures performances, vous pouvez également optimiser la configuration du pool PHP-FPM :

# Modifier le fichier www.conf
sudo vim /etc/php/8.3/fpm/pool.d/www.conf

Trouvez et modifiez ces paramètres :

; Paramètres du gestionnaire de processus
pm = dynamic                  ; Gestionnaire de processus dynamique
pm.max_children = 50          ; Nombre maximum de processus enfants
pm.start_servers = 5          ; Nombre de processus enfants créés au démarrage
pm.min_spare_servers = 5      ; Nombre minimum de processus serveur inactifs
pm.max_spare_servers = 35     ; Nombre maximum de processus serveur inactifs
pm.max_requests = 500         ; Nombre de requêtes que chaque processus enfant doit exécuter avant de se relancer

Ajustement des paramètres PHP-FPM

Les valeurs optimales pour ces paramètres dépendent de la mémoire disponible et du CPU de votre serveur. Pour un serveur avec 4 Go de RAM, les valeurs ci-dessus sont un bon point de départ. Pour les serveurs avec plus de ressources, vous pouvez augmenter ces valeurs proportionnellement.

11.5.3. Application des modifications

Après avoir effectué ces modifications, redémarrez PHP-FPM et rechargez Nginx :

# Redémarrer PHP-FPM
sudo systemctl restart php8.3-fpm

# Recharger Nginx
sudo systemctl reload nginx

11.6. Conclusion

Vous avez maintenant durci et optimisé avec succès votre pile LEMP (Linux, Nginx, MariaDB et PHP) pour l’hébergement WordPress. Ces configurations fournissent un bon équilibre entre sécurité et performances pour la plupart des sites WordPress.

N’oubliez pas de surveiller les performances de votre serveur et d’ajuster ces paramètres selon vos besoins en fonction de votre charge de travail spécifique et de vos schémas de trafic. Des outils comme MySQLTuner, les pages d’état Nginx et les pages d’état PHP-FPM peuvent vous aider à identifier les goulots d’étranglement et à affiner votre configuration.