translation

Texte traduit par l'IA.

뚠뚠멍의 생각들

Paramètres principaux de nginx en tant que serveur Web

Image de profil

Résumé du texte par durumis AI

  • Nous avons traité les principaux paramètres pour optimiser les performances du serveur Web nginx, notamment la compression gzip, la configuration de proxy_buffer, et la configuration des processus worker et keep-alive.
  • Nous avons particulièrement insisté sur l'importance de la compression gzip et de la mise en mémoire tampon proxy_buffer pour réduire le volume de données transférées et minimiser la charge du serveur, ainsi que sur la gestion des connexions grâce à la configuration des processus worker et keep-alive.
  • Nous avons effectué divers tests pour appliquer les paramètres optimaux à votre environnement serveur et avons fourni des précautions pour une exploitation stable du serveur.

Nginx est un serveur web open source, souvent utilisé comme serveur web ou serveur proxy web.

Avec une configuration appropriée, il peut fournir du contenu statique de manière efficace.

Je souhaite documenter ici quelques-uns de ses principaux paramètres de configuration.


Quelques paramètres clés liés aux performances

1. Compression gzip

Lors du chargement d'un site web, de nombreux fichiers sont reçus du serveur web, tels que des scripts JavaScript, des images, du code HTML et des feuilles de style CSS.

Au lieu de transmettre ce contenu tel quel, l'utilisation de la compression gzip permet de réduire significativement la quantité de données transmises.


En d'autres termes, son application permet :

- Une réduction de la quantité de données, entraînant des économies de bande passante.

- Des économies de ressources serveur.

- Une amélioration de la vitesse de chargement pour l'utilisateur.


En revanche, comme le serveur doit effectuer la compression gzip avant d'envoyer la réponse, l'utilisation du processeur peut augmenter.

Il est donc essentiel de tester avant la mise en production, notamment le type de fichiers à compresser, le niveau de compression et la taille minimale des fichiers à compresser.


Voici quelques paramètres liés à gzip :


gzip on; # Active la compression gzip.
gzip_vary on; # Ajoute l'en-tête Vary: Accept-Encoding.
gzip_proxied any; # Si nginx est utilisé comme proxy, compresse la réponse reçue du backend. (Compression des requêtes proxy)
gzip_min_length 256; # Compresse uniquement les fichiers de 256 octets ou plus.
gzip_comp_level 5; # Définit le niveau de compression de 1 à 9. Plus il est élevé, plus l'utilisation du processeur est importante. 5 correspond à environ 50 % de compression.
gzip_types text/plain text/css text/xml application/json application/javascript;
// Définit les types de contenu à compresser.

* gzip_vary indique que le contenu peut être envoyé en version compressée ou non compressée selon que le client supporte gzip ou non. (Indique que le contenu peut être fourni en différentes versions selon l'en-tête de requête du client (Accept-Encoding)).


2. Paramètre proxy_buffer

Nginx stocke la réponse dans un tampon avant de l'envoyer au client.

Lorsque le serveur web envoie une réponse au client, si le client est lent, le serveur doit attendre. (Bouchon réseau)

Dans ce cas, les ressources du serveur sont utilisées en continu. Pour résoudre ce problème, un tampon est utilisé pour traiter temporairement la réponse indépendamment de la vitesse de traitement du client. Cela présente les avantages suivants :

- Optimisation de la charge du serveur

- Réduction des goulots d'étranglement du réseau

  
location / {
proxy_pass adresse_du_serveur;
        # Configuration du tampon proxy
        proxy_buffering on; # Active le tampon.
        proxy_buffer_size 4k; # Définit la taille du tampon. (Principalement pour les en-têtes).
        proxy_buffers 8 4k; # Nombre et taille des tampons pour chaque connexion (8 tampons de 4 ko)
        proxy_busy_buffers_size 8k; # Taille maximale du tampon utilisable lors de l'envoi de la réponse au client.

    }

※ Si la taille du tampon est trop grande, la transmission de données en temps réel, telle que la diffusion en continu de texte, peut être retardée. Des tests sont donc nécessaires. Notamment, avec le développement récent des services d'IA, il est crucial de vérifier ce paramètre si la diffusion en continu de texte ne fonctionne pas.


3. Configuration worker et http

Les workers sont les processus qui traitent les requêtes des clients. On peut définir le nombre de workers par cœur de processeur du serveur.

HTTP implique généralement une requête-connexion-réponse-déconnexion. Pour réduire les ressources utilisées pour les connexions lors de plusieurs requêtes, la connexion client peut être maintenue. Il s'agit de la configuration keep-alive.


worker_processes auto; # Configuration automatique en fonction du nombre de cœurs CPU disponibles.
worker_connections 1024; # Nombre de connexions qu'un worker peut traiter simultanément.


# Configuration keep-alive
keepalive_timeout 65;
keepalive_requests 100;

server {
    listen 80;

    location / {
        proxy_pass adresse_du_serveur;
    }
}

La raison de regrouper ces deux éléments est la suivante :

Si le serveur possède 4 cœurs, le nombre théorique de connexions possibles est de 1 024 × 4 = 4 096.

(Ce nombre peut ne pas être exact en fonction des ressources et de l'environnement du trafic)

Si 4 096 clients sont connectés simultanément et occupent tous les keep-alive pendant 65 secondes,

la connexion du 4 097e utilisateur peut être impossible, ce qui peut entraîner des retards de réponse.


Par conséquent, en supposant que les ressources du serveur sont stables grâce à une mise à l'échelle automatique, si un retard de réponse se produit lors d'un événement, la configuration ci-dessus peut avoir un impact indirect.


4. Autres - bloc location

Certains paramètres, tels que le tampon proxy, peuvent être appliqués à chaque URL de requête.

* Certains paramètres, tels que keep-alive, sont appliqués au niveau du serveur HTTP et ne peuvent pas être configurés par bloc.

server {
listen 80;
server_name example.com;

# Traitement du chemin de base (/)
location / {
    proxy_pass adresse_du_serveur;

    # Configuration du tampon
    proxy_buffering on;                   
    proxy_buffers 8 16k;                  
    proxy_buffer_size 32k;                
    proxy_busy_buffers_size 64k;          
}

# Traitement du chemin /test
location /test {
    proxy_pass adresse_du_serveur2;

    # Désactivation du tampon
    proxy_buffering off;                  # Désactivation du tampon (envoi immédiat de la réponse)
}
}


Ces paramètres permettent d'optimiser les performances web. Après avoir effectué des tests avec différents cas, optimisez les performances de votre serveur !

* La configuration nginx mise à jour peut être appliquée sans temps d'arrêt du serveur, ce qui la rend généralement stable.






뚠뚠멍
뚠뚠멍의 생각들
뚠뚠멍
Mesurer les performances d'un site Web - PerformanceObserverDécouvrez PerformanceObserver, un outil de mesure des performances de site Web, et des conseils pour améliorer les Web Core Vitals. Explorez des méthodes concrètes pour optimiser les indicateurs CLS, LCP, FCP et FID.

September 24, 2024

Problèmes de cross-browsing que j'ai rencontrés (principalement Safari)Cet article décrit les problèmes de cross-browsing (principalement sur Safari) rencontrés lors du développement web mobile et leurs solutions. Il traite notamment des problèmes de calcul de la hauteur de la viewport, des problèmes de décalage de l'interfa

September 27, 2024

Les règles de base du CSS (Flux normal, BFC, IFC)Cet article explique les règles de base du CSS, à savoir le flux normal, le BFC et l'IFC, et fournit les connaissances nécessaires à la construction de mises en page et à la conception responsive.

September 7, 2024

Utiliser Google Cloud Storage et Cloud Run pour un CDN - 2Deuxième article sur la mise en place d'un CDN en utilisant Google Cloud Storage et Cloud Run. Nous allons expliquer comment optimiser la transmission des images et des fichiers texte, et comment déployer les ressources dans 8 régions du monde pour réduir
두루미스 기술 블로그
두루미스 기술 블로그
두루미스 기술 블로그
두루미스 기술 블로그

September 6, 2024

Utiliser Cloud Run pour servir des fichiers statiques - 1Article de blog sur la manière de servir des fichiers statiques à l'aide de Google Cloud Run. L'accent est mis sur la redirection et l'amélioration des performances.
두루미스 기술 블로그
두루미스 기술 블로그
두루미스 기술 블로그
두루미스 기술 블로그

September 4, 2024

[DB] Définition des critères de configuration du cacheCet article présente les critères de configuration du cache de base de données et des exemples d'application concrets. Nous expliquons comment mettre en cache les données qui sont fréquemment lues mais rarement écrites, et comment maintenir l'actualité de
제이온
제이온
제이온
제이온

April 25, 2024

Optimisation et synchronisation d'images à l'aide de Google Cloud Storage et Cloud Run - 3Cet article explique comment optimiser les images et les synchroniser sur plusieurs régions à l'aide de Google Cloud Storage et Cloud Run. Il aborde la mise en œuvre des fonctionnalités de conversion, de réplication et de suppression de fichiers image.
두루미스 기술 블로그
두루미스 기술 블로그
두루미스 기술 블로그
두루미스 기술 블로그

September 8, 2024

[Spring] Filter, Interceptor, Argument Resolver, qu'est-ce que c'est ?Cet article explique le rôle et la mise en œuvre des filtres, intercepteurs et Argument Resolver dans Spring, ainsi que leurs différences. Les filtres et les intercepteurs gèrent le traitement avant et après une requête, tandis que Argument Resolver trait
제이온
제이온
제이온
제이온

April 27, 2024

[Hors informatique, survivre en tant que développeur] 14. Résumé des questions techniques fréquemment posées lors d'un entretien d'embauche pour développeur débutantNous avons résumé et organisé les questions techniques fréquemment posées lors des entretiens d'embauche pour les développeurs débutants (zones de mémoire, structures de données, bases de données, etc.). Nous espérons que cela vous aidera dans votre prépa
투잡뛰는 개발 노동자
투잡뛰는 개발 노동자
투잡뛰는 개발 노동자
투잡뛰는 개발 노동자

April 3, 2024