Réduire la charge du serveur

Dans cet article, nous analyserons les causes de l'augmentation de la charge serveur et aborderons les différentes manières d'optimiser les processus à forte charge. Nous nous concentrerons sur l'optimisation du code dans Apache/Nginx et MySQL, nous aborderons la mise en cache comme outil auxiliaire et nous examinerons les menaces externes potentielles, telles que les attaques DDoS, et les moyens de les prévenir.

Pourquoi la charge du serveur se produit

Avant de procéder à l'optimisation du serveur, il est nécessaire de procéder à une analyse approfondie de la charge actuelle des ressources. Cela inclut la mesure de la charge du processeur, de l'utilisation de la RAM, de l'activité réseau et d'autres paramètres clés. Comprendre la dynamique et les pics de charge permet d'identifier les goulots d'étranglement et d'optimiser l'allocation des ressources, augmentant ainsi la stabilité et les performances de l'infrastructure serveur.

Pour le dépannage initial d'une charge de serveur élevée, nous vous recommandons d'effectuer une diagnostics généraux du serveurSi cela n'est pas suffisant, une description plus détaillée analyse des ressources est nécessaire. En tant qu'outil auxiliaire, l'exploration de journaux de Linux Le serveur peut être utile, car c'est là que se trouve la source du problème dans la plupart des cas.

Optimisation du serveur Apache/Nginx

Augmentation de la charge du serveur en raison de l'indexation

Une charge serveur accrue due à l'indexation peut survenir, par exemple, lorsque les moteurs de recherche analysent un grand nombre de pages de votre site. Cela peut entraîner une utilisation accrue des ressources serveur et, par conséquent, ralentir les performances du site. Identifier la cause est relativement simple : il suffit d'ouvrir le fichier situé à l'adresse suivante :

/var/www/httpd-logs/sitename.access.log

Lorsqu'il est indexé par les moteurs de recherche, l'utilisateur verra des entrées de la nature suivante :

11.22.33.44 - - [Date and Time] "GET /your-page-path HTTP/1.1" 200 1234 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Comme première solution pour réduire la charge, vous pouvez utiliser le paramétrage des balises méta "pas d'index" et "pas de suivi" sur les pages qui n'ont pas besoin d'être indexées. La deuxième solution est la .htaccess fichier, où les entrées correspondant à des moteurs de recherche spécifiques doivent être ajoutées, par exemple, pour se cacher de Yandex et de Google :

SetEnvIfNoCase User-Agent "^Yandex" search_bot
SetEnvIfNoCase User-Agent "^Googlebot" search_bot
Order Allow,Deny
Allow from all
Deny from env=search_bot

De même, des modifications doivent être apportées aux autres moteurs de recherche. Il est à noter que les fonctionnalités de .htaccess ne se limitent pas au blocage de l'indexation. Nous vous recommandons de vous familiariser avec ses principales fonctionnalités dans le article.

Utilisation des paramètres de mise en cache

Des paramètres de mise en cache incorrects sur le serveur peuvent également entraîner une charge élevée. Pour optimiser ce paramètre, des modifications doivent être apportées aux fichiers de configuration. .htaccessDans le cas d’Apache, la dernière option est préférable, pour Nginx, la première.

Sur un Apache serveur, vous devez ouvrir le .htaccess fichier et insérez le code suivant :

<FilesMatch ".(flv|gif|jpg|jpeg|png|ico|swf|js|css|pdf|doc|docx)$">
Header set Cache-Control "max-age=2592000"
</FilesMatch>

Ensuite, activez le Expire le module utilisant la commande :

sudo a2enmod expires

Après quoi, redémarrez le serveur Web :

sudo service apache2 restart

Et activez le module en spécifiant :

ExpiresActive On

Sur un Nginx serveur, il suffit d'ajouter le code suivant au fichier de configuration :

location ~* .(jpg|jpeg|gif|png|ico|css|swf|flv|doc|docx)$ {
root /var/www/yoursite.com;
}

Et effectuez un rechargement de service :

sudo service nginx restart

Notez qu'avec ces paramètres, le Autoriser et Refuser les directives seront contournées.

Utilisation de la compression de données

Activation de la compression des données à l'aide de gzip sur les serveurs Web Apache et Nginx, cela permet de réduire la quantité de données transmises entre le serveur et le client, ce qui améliore les performances et réduit le temps de chargement des pages Web.

Autoriser gzip on Apache, vous devez activer le mod_deflate module:

sudo a2enmod deflate

Ensuite, redémarrez le serveur Web :

sudo service apache2 restart

Et enfin, ajoutez le bloc suivant au fichier de configuration ou .htaccess :

<IfModule mod_deflate.c>
# Configure compression for specified file types
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/x-javascript application/json

# If the browser matches the specified pattern, apply compression only to text/html files
BrowserMatch ^Mozilla/4 gzip-only-text/html

# If the browser matches the specified version patterns of Mozilla 4.0.6, 4.0.7, 4.0.8, disable compression
BrowserMatch ^Mozilla/4\.0[678] no-gzip

# If the browser is MSIE (Internet Explorer), disable compression for all files except text/html
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

# If the request contains the specified pattern (extensions of image files), disable compression
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip
</IfModule>

Cette configuration active la compression pour certains types de fichiers et la désactive pour les images.

Dans le cas d' Nginx, la configuration se produit dans le http Bloc du fichier de configuration. Le code suivant doit être ajouté :

gzip on;
gzip_disable "msie6";

# Adds the Vary header, indicating that the response may change depending on the Accept-Encoding header value
gzip_vary on;

# Enables compression for any proxy servers
gzip_proxied any;

# Sets the compression level. A value of 6 provides a good balance between compression efficiency and resource use
gzip_comp_level 6;

# Sets the size of the buffer for compressed data (16 buffers of 8 kilobytes each)
gzip_buffers 16 8k;

# Specifies that data compression should be used only for HTTP version 1.1 and higher
gzip_http_version 1.1;

# Sets the file types that can be compressed
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

Similaire à Apache, ici sont définis les paramètres de compression pour certains types de fichiers. Après avoir modifié l'un des serveurs web, un rechargement du service est nécessaire :

sudo service apache2 restart

Or

sudo service nginx restart

Attaque DDOS sur le serveur

Une attaque DDoS peut entraîner une surcharge du serveur. L'identification d'une attaque DDoS peut se faire en surveillant une augmentation soudaine du trafic, des requêtes anormales et des baisses de performances du serveur. L'analyse des journaux de requêtes répétées provenant d'une même adresse IP ou l'analyse des ports peuvent également indiquer une possible attaque DDoS. Il existe de nombreuses mesures de protection, mais nous n'aborderons que les bases.

Utiliser un CDN (Content Delivery Network)Un CDN peut servir d'intermédiaire entre votre serveur web et vos utilisateurs, en répartissant le trafic et en mettant en cache le contenu afin d'atténuer l'impact d'une attaque DDoS. Les CDN peuvent également intégrer des mécanismes de protection DDoS, notamment la répartition de la charge et le filtrage du trafic.

Configuration des pare-feu et des systèmes de détection d'intrusion (IDS/IPS)Les pare-feu peuvent être configurés pour filtrer le trafic selon divers critères, tels que les adresses IP et les ports. Les systèmes IDS/IPS peuvent détecter les comportements anormaux du trafic et bloquer les connexions suspectes. Ces outils peuvent être efficaces pour suivre et bloquer le trafic potentiellement malveillant.

Configuration des serveurs Web Apache et Nginx pour atténuer l’impact des attaques DDoS.

En tant que solution pour Apache, nous activons le mod_evasive module. Pour ce faire, supprimez le commentaire ou ajoutez la ligne suivante dans le httpd.conf or apache2.conf fichier de configuration:

LoadModule evasive20_module modules/mod_evasive.so

Dans le même fichier, vous devez ajouter un bloc de paramètres :

<IfModule mod_evasive20.c>
# Hash table size for storing request information
DOSHashTableSize 3097

# Number of requests to one page before activating protection
DOSPageCount 2
DOSPageInterval 1

# Number of requests to all pages before activating protection
DOSSiteCount 50
DOSSiteInterval 1

# Blocking period in seconds for IP addresses
DOSBlockingPeriod 10
</IfModule>

De la même manière, nous activons le mod_ratelimit module:

LoadModule ratelimit_module modules/mod_ratelimit.so

Et ajoutez la configuration :

<IfModule mod_ratelimit.c>
# Setting the output filter for rate limiting (Rate Limit)
SetOutputFilter RATE_LIMIT

# Beginning of the settings block for the location "/login"
<Location "/login">

# Setting the environment variable rate-limit with a value of 1
SetEnv rate-limit 1

# Ending of the settings block for the location "/login"
</Location>
</IfModule>

La configuration pour Nginx est similaire à Apache. Dans le nginx.conf fichier de configuration, les directives suivantes doivent être utilisées :

http {
...
# Defining a zone for connection limits
limit_conn_zone $binary_remote_addr zone=addr:10m;

# Defining a zone for request limits
limit_req_zone $binary_remote_addr zone=req_zone:10m rate=1r/s;

server {
        ...
        # Configuring connection limits
        limit_conn addr 10;

        # Configuring request limits
        limit_req zone=req_zone burst=5;

        ...
    }
}

Après avoir apporté des modifications à chacun des services, ils doivent être rechargés :

sudo systemctl restart apache2

Ou:

sudo systemctl restart nginx

Ces exemples ne fournissent qu'une configuration de base, qui peut être adaptée en fonction des exigences spécifiques et de la nature des attaques.

Optimisation des requêtes MySQL

L'optimisation des requêtes de base de données MySQL sur un serveur web peut se faire de différentes manières, notamment en configurant correctement le fichier de configuration. Ce fichier est généralement nommé mon.cnf or mon.ini et est situé dans le / Etc / or /etc/mysql/ répertoire. Vous devez l'ouvrir et y apporter les modifications suivantes :

[mysqld]
# Location of the file for recording slow queries. Be sure to replace it with your path
log-slow-queries = /var/log/mariadb/slow_queries.log

# Threshold time for considering slow queries (in seconds)
long_query_time = 5

# Enabling recording of queries that do not use indexes
log-queries-not-using-indexes = 1

# Disabling query caching
query_cache_size = 0
query_cache_type = 0
query_cache_limit = 1M

# Size of temporary tables
tmp_table_size = 16M
max_heap_table_size = 16M

# Size of the thread cache
thread_cache_size = 16

# Disabling name resolving
skip-name-resolve = 1

# Size of the InnoDB buffer pool. Set to 50-70% of available RAM
innodb_buffer_pool_size = 800M

# Size of the InnoDB log file
innodb_log_file_size = 200M

Considérons également des recommandations supplémentaires qui peuvent faciliter l’interaction avec la base de données du serveur :

1. Utilisez le bouton EXPLIQUE Commande avant une requête SQL pour analyser son exécution. Cela permet d'obtenir un plan d'exécution de la requête et de déterminer les index utilisés, les tables analysées, etc.
2. Les index accélèrent la recherche de données ; des index bien conçus peuvent donc améliorer considérablement les performances des requêtes. Soyez attentif aux colonnes fréquemment utilisées. OÙ or INSCRIPTION conditions.
3. Évitez d'utiliser SELECT *. Spécifiez uniquement les colonnes qui sont vraiment nécessaires à votre requête, au lieu de sélectionner toutes les colonnes d'une table.
4. Évitez d'utiliser des fonctions dans OÙ conditions. En utilisant des fonctions (telles que BAS, UPPER, en stock, DROIT) dans OÙ Les conditions peuvent rendre les index inutiles. Évitez leur utilisation directe dans les conditions.
5. Utilisez le JOINTURE INTERNE Dans la mesure du possible, car c'est généralement plus efficace. Assurez-vous également que les colonnes correspondantes à la jointure possèdent des index.
6. Utilisez le LIMIT pour restreindre le nombre de lignes renvoyées si vous avez besoin d'obtenir seulement un certain nombre de résultats.
7. Envisagez de mettre en cache les résultats des requêtes, surtout s’ils changent rarement, pour réduire la charge du serveur.

Le serveur de messagerie crée une charge élevée sur le serveur

Dans cette section, nous verrons comment déterminer si le serveur de messagerie subit une charge élevée et quelles mesures peuvent être prises pour optimiser son fonctionnement, notamment en vérifiant la file d'attente des messages et en configurant les paramètres du serveur. Commencez par vérifier la file d'attente des messages. mailq L'utilitaire peut vous aider, pour l'activer, entrez la commande correspondante dans le terminal :

mailq

Cela affichera la liste des messages en file d'attente, le cas échéant. Chaque message sera affiché avec son identifiant unique et des informations sur son statut d'envoi. Un résultat similaire peut être obtenu en consultant les journaux du client de messagerie.

Dans la plupart des cas, une surcharge survient en cas de compromission du serveur, lorsque celui-ci commence à envoyer du spam. Cependant, si, après vérification, l'administrateur est certain que le serveur n'a pas été attaqué de l'extérieur et que les utilisateurs ne négligent pas le spam, il est temps d'optimiser le serveur de messagerie. Voici les étapes à suivre :

1. Assurez-vous que les enregistrements DNS de votre domaine sont correctement configurés, y compris SPF, DKIM et DMARC Enregistrements pour améliorer la distribution du courrier et se protéger contre le spam. La configuration correcte des paramètres est disponible dans l'article sur diagnostic du serveur de messagerie.
2. Vérifiez les paramètres réseau, y compris la configuration du pare-feu et les règles de routage, pour éviter les blocages et accélérer la distribution du courrier.
3. Configurez les paramètres de la file d'attente de messages en fonction de la charge du serveur. Cela peut inclure la définition de la taille maximale de la file d'attente et des délais d'expiration.
4. Pensez aux solutions évoquées précédemment dans cet article. Optimisez régulièrement la base de données du serveur de messagerie pour améliorer les performances et utilisez des mécanismes de mise en cache pour accélérer la recherche et le traitement des données, comme les requêtes DNS.
5. Si le serveur de messagerie rencontre encore régulièrement une charge élevée, envisagez des options de mise à l'échelle, telles que l'utilisation d'un cluster de serveurs de messagerie ou de solutions cloud.

Conclusion

L'augmentation de la charge serveur affecte directement la vitesse de chargement du site web, ce qui impacte in fine l'expérience utilisateur et la réputation dans les moteurs de recherche. Une gestion efficace de cette charge joue donc un rôle essentiel pour garantir la fonctionnalité continue de la ressource et améliorer son accessibilité pour les visiteurs.