{"id":20906,"date":"2026-08-22T18:18:36","date_gmt":"2026-08-22T16:18:36","guid":{"rendered":"https:\/\/webhosting.de\/nginx-sendfile-tcp-nopush-ratgeber-performance-setup\/"},"modified":"2026-08-22T18:18:36","modified_gmt":"2026-08-22T16:18:36","slug":"nginx-sendfile-tcp-nopush-guide-performance-configuration","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/nginx-sendfile-tcp-nopush-ratgeber-performance-setup\/","title":{"rendered":"Utiliser correctement NGINX sendfile et tcp_nopush pour des performances optimales"},"content":{"rendered":"<p>Avec <strong>nginx sendfile<\/strong> et <strong>tcp_nopush<\/strong> Je transmets les fichiers statiques en \u00ab zero-copy \u00bb depuis le syst\u00e8me de fichiers vers le socket, ce qui r\u00e9duit sensiblement la charge du processeur et le nombre de paquets. Correctement configur\u00e9es, ces deux directives am\u00e9liorent l'efficacit\u00e9 du transfert, r\u00e9duisent la surcharge et posent les bases d'une optimisation nginx efficace pour les ressources et les t\u00e9l\u00e9chargements.<\/p>\n\n<h2>Points centraux<\/h2>\n\n<ul>\n  <li><strong>Zero-Copy<\/strong> gr\u00e2ce \u00e0 sendfile : moins de copies, un d\u00e9bit plus \u00e9lev\u00e9<\/li>\n  <li><strong>tcp_nopush<\/strong> met les paquets en m\u00e9moire tampon : trames plus volumineuses, moins de surcharge<\/li>\n  <li><strong>Combinaison<\/strong> comprend : sendfile + tcp_nopush + tcp_nodelay<\/li>\n  <li><strong>Cas d'utilisation<\/strong> hi\u00e9rarchiser : ressources statiques, fichiers volumineux \u00e0 t\u00e9l\u00e9charger<\/li>\n  <li><strong>Tests<\/strong> pour NFS\/SMB : mesurer l'impact, d\u00e9sactiver sendfile si n\u00e9cessaire<\/li>\n<\/ul>\n\n<h2>Pourquoi la fonction `sendfile` am\u00e9liore autant les performances de NGINX<\/h2>\n\n<p>J'active <strong>sendfile<\/strong>, car le noyau peut envoyer des fichiers directement via la pile r\u00e9seau, sans passer par des op\u00e9rations de copie suppl\u00e9mentaires dans l'espace utilisateur. Ce chemin \u00ab z\u00e9ro copie \u00bb r\u00e9duit les changements de contexte et \u00e9conomise des cycles CPU, en particulier lorsque de nombreux clients simultan\u00e9s r\u00e9cup\u00e8rent du contenu statique. Les fichiers volumineux tels que les images, les fichiers CSS, JavaScript ou les archives en b\u00e9n\u00e9ficient, car le transfert de donn\u00e9es s\u2019effectue de mani\u00e8re plus fluide et avec moins de surcharge. Les caches syst\u00e8me fonctionnent \u00e9galement plus efficacement, car il y a moins de mouvements de m\u00e9moire et c\u2019est le noyau qui contr\u00f4le le cheminement des donn\u00e9es. C\u2019est sur les syst\u00e8mes de fichiers locaux que le gain est le plus flagrant, c\u2019est pourquoi je commence par y effectuer mes mesures avant de transposer les r\u00e9sultats \u00e0 des configurations plus exotiques.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx-server-setup-8934.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ce que fait exactement tcp_nopush et dans quelles circonstances il se distingue<\/h2>\n\n<p>Avec <strong>tcp_nopush<\/strong> Je demande au syst\u00e8me de n'envoyer les paquets TCP que lorsqu'ils sont suffisamment remplis, plut\u00f4t que d'envoyer trop t\u00f4t de petits segments. Sous Linux, cela correspond \u00e0 TCP_CORK, sous FreeBSD \u00e0 TCP_NOPUSH, et dans les deux cas, le nombre de paquets diminue de mani\u00e8re mesurable. Cette directive ne r\u00e9duit pas la latence au minimum ; elle vise \u00e0 am\u00e9liorer le rapport entre les donn\u00e9es utiles et la surcharge. J\u2019utilise tcp_nopush de mani\u00e8re cibl\u00e9e pour les fichiers statiques, car c\u2019est l\u00e0 que les flux de donn\u00e9es contigus offrent les gains d\u2019efficacit\u00e9 les plus importants. Sans sendfile, tcp_nopush reste sans effet ; c\u2019est pourquoi j\u2019int\u00e8gre toujours ces deux param\u00e8tres ensemble.<\/p>\n\n<h2>sendfile et tcp_nopush en tandem : voici comment je pose les bases<\/h2>\n\n<p>La combinaison de <strong>sendfile<\/strong> et tcp_nopush r\u00e9duit les copies et regroupe les paquets, ce qui permet \u00e0 un serveur par c\u0153ur de processeur de g\u00e9rer nettement plus de transferts parall\u00e8les. Je configure ces deux param\u00e8tres au niveau du contexte http et j'ajoute souvent tcp_nodelay afin que les derniers restes d'un flux puissent s'\u00e9couler sans temps d'attente. Il reste important de proc\u00e9der \u00e0 des tests avec du trafic r\u00e9el, car la taille des paquets, le MTU et les clients varient, et le meilleur \u00e9quilibre peut l\u00e9g\u00e8rement diff\u00e9rer en fonction de la charge de travail. Pour les r\u00e9pertoires statiques, l\u2019activation globale suffit g\u00e9n\u00e9ralement, tandis que pour les routes de r\u00e9ponse dynamiques, je surveille l\u2019impact. Cette combinaison offre une base solide pour d\u2019autres \u00e9tapes d\u2019optimisation d\u2019Nginx, qui viendront s\u2019y ajouter par la suite.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>directive<\/th>\n      <th>Objectif<\/th>\n      <th>Effet typique<\/th>\n      <th>D\u00e9pendance<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>sendfile activ\u00e9<\/strong><\/td>\n      <td>Copie sans transfert de fichier vers le socket<\/td>\n      <td>Moins de charge sur le processeur, d\u00e9bit plus \u00e9lev\u00e9<\/td>\n      <td>Syst\u00e8me de fichiers local : l'id\u00e9al<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>tcp_nopush activ\u00e9<\/strong><\/td>\n      <td>Remplir les colis, r\u00e9duire les frais g\u00e9n\u00e9raux<\/td>\n      <td>Moins de segments par fichier<\/td>\n      <td>Ne fonctionne qu'avec sendfile<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>tcp_nodelay activ\u00e9<\/strong><\/td>\n      <td>Envoyer les derniers octets sans d\u00e9lai<\/td>\n      <td>Ach\u00e8vement rapide du transfert<\/td>\n      <td>Ajout de tcp_nopush<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx_performance_meeting_8371.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Voici comment tcp_nodelay interagit avec tcp_nopush<\/h2>\n\n<p>J'active <strong>tcp_nopush<\/strong>, afin d'envoyer le d\u00e9but d'un transfert par paquets plus volumineux, tout en activant tcp_nodelay pour \u00e9viter que la fin du transfert ne soit bloqu\u00e9e. Ces deux param\u00e8tres agissent sur des phases diff\u00e9rentes du flux et ne se g\u00eanent pas mutuellement lorsque NGINX transf\u00e8re des fichiers via sendfile. C\u2019est notamment dans le cas de nombreux petits fichiers que tcp_nodelay \u00e9vite au client d\u2019attendre inutilement en raison de petites quantit\u00e9s de donn\u00e9es restantes. Je teste d\u2019abord cette combinaison en environnement de pr\u00e9production, j\u2019observe les temps de transit (RTT) et la taille des segments, puis je les compare aux m\u00e9triques en production. Je m\u2019assure ainsi d\u2019une efficacit\u00e9 au d\u00e9but et d\u2019une rapidit\u00e9 \u00e0 la fin du transfert.<\/p>\n\n<pre><code>http {\n    sendfile on;\n    tcp_nopush on;\n    tcp_nodelay on;\n}\n<\/code><\/pre>\n\n<h2>Sc\u00e9narios d'utilisation typiques : lorsque les directives ont un impact important<\/h2>\n\n<p>Pour les grandes <strong>T\u00e9l\u00e9chargements<\/strong> Comme pour les vid\u00e9os, les archives ou les images ISO, le chemin \u00ab zero-copy \u00bb du noyau r\u00e9duit consid\u00e9rablement le temps CPU par transfert. Dans les configurations de type CDN comportant de nombreux fichiers CSS, JS et de polices, tcp_nopush permet d\u2019\u00e9conomiser des segments et augmente ainsi la bande passante utilisable par socket. Sur les sites WordPress bien mis en cache, la plupart des requ\u00eates concernent des ressources statiques, c\u2019est pourquoi j\u2019y constate tr\u00e8s rapidement un effet positif. Les artefacts de build, les images de conteneurs ou les programmes d\u2019installation en b\u00e9n\u00e9ficient \u00e9galement, \u00e0 condition qu\u2019ils soient stock\u00e9s localement et ne transitent pas par un syst\u00e8me de fichiers r\u00e9seau instable. Si vous vous attendez \u00e0 des pics de charge, ce duo vous permettra de tirer le maximum de stabilit\u00e9 du mat\u00e9riel dont vous disposez.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx-performance-optimization-2378.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Exemple pratique : NGINX pour WordPress avec mise en cache et ressources<\/h2>\n\n<p>Dans les installations WordPress, j'utilise <strong>sendfile<\/strong>, j'active les options `tcp_nopush` et `tcp_nodelay` au niveau global, je fournis directement les ressources statiques et je veille \u00e0 bien s\u00e9parer PHP-FPM des chemins dynamiques. J\u2019ajoute des en-t\u00eates de cache pertinents pour les images, les feuilles de style CSS et les scripts JavaScript, afin que les navigateurs effectuent moins d\u2019allers-retours. Lorsque je fournis des r\u00e9ponses de type streaming, je tiens compte de l\u2019interaction avec la mise en m\u00e9moire tampon et je teste l\u2019impact de la taille des blocs sur la latence et le d\u00e9bit ; \u00e0 ce sujet, l\u2019aper\u00e7u sur <a href=\"https:\/\/webhosting.de\/fr\/http-response-streaming-hosting-performance-chunks\/\">Streaming de r\u00e9ponse en chunks<\/a>. Pour les contenus textuels, j'utilise la compression sans compresser inutilement les fichiers binaires. Cela permet de maintenir un flux de requ\u00eates stable, de ne pas surcharger le processeur et de r\u00e9duire le temps de r\u00e9ponse (Time-to-First-Byte).<\/p>\n\n<pre><code>http {\n    sendfile on;\n    tcp_nopush on;\n    tcp_nodelay on;\n\n keepalive_timeout 65;\n    gzip on;\n    gzip_types text\/css application\/javascript image\/svg+xml;\n\n    server {\n listen 80;\n server_name blog.example.com;\n root \/var\/www\/blog;\n\n location \/ {\n try_files $uri $uri\/ \/index.php?$args;\n }\n\n        location ~ \\.php$ {\n include fastcgi_params;\n fastcgi_pass unix:\/run\/php\/php-fpm.sock;\n            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;\n }\n\n location ~* \\.(jpg|jpeg|png|gif|css|js|ico|svg|woff2?)$ {\n expires 30d;\n add_header Cache-Control \"public, max-age=2592000\";\n }\n    }\n}\n<\/code><\/pre>\n\n<h2>Quand je d\u00e9sactive d\u00e9lib\u00e9r\u00e9ment la fonction sendfile<\/h2>\n\n<p>J'enclenche <strong>sendfile<\/strong> lorsque les fichiers se trouvent sur des syst\u00e8mes de fichiers NFS, SMB ou distribu\u00e9s, qui, lors de mes tests, ont affich\u00e9 des d\u00e9bits moins performants. Certains pilotes ou certaines latences dans le chemin de stockage annulent l\u2019avantage du \u00ab zero-copy \u00bb, c\u2019est pourquoi les mesures font office de r\u00e9f\u00e9rence. En cas d\u2019anomalies r\u00e9seau sporadiques, je d\u00e9sactive d\u2019abord tcp_nopush afin de circonscrire les effets avant de remettre en question sendfile lui-m\u00eame. Des bogues inhabituels du noyau ou des piles plus anciennes peuvent \u00e9galement justifier le passage temporaire au chemin de lecture-\u00e9criture classique. Il reste important d\u2019appliquer les modifications progressivement et de les \u00e9tayer par des m\u00e9triques.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx_performance_3456.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Les sources d'erreurs que je surveille de pr\u00e8s<\/h2>\n\n<p>Je v\u00e9rifie d'abord si <strong>tcp_nopush<\/strong> est activ\u00e9e par inadvertance alors que sendfile reste d\u00e9sactiv\u00e9, car dans ce cas, le param\u00e8tre n'a aucun effet. Pour les chemins d'acc\u00e8s dynamiques, je v\u00e9rifie si une mise en m\u00e9moire tampon suppl\u00e9mentaire augmente la latence et je mets en balance les avantages et le temps de r\u00e9ponse. Sur les r\u00e9seaux \u00e0 forte latence, je v\u00e9rifie si des paquets plus volumineux sont r\u00e9ellement utiles ou si je dois ajuster la taille des segments et les keep-alive. La configuration du MTU et les fonctionnalit\u00e9s de d\u00e9chargement de la carte r\u00e9seau peuvent \u00e9galement modifier sensiblement le r\u00e9sultat. Des journaux clairs, des \u00e9chantillons pcap et des m\u00e9triques syst\u00e8me corr\u00e9l\u00e9es m\u2019indiquent rapidement o\u00f9 effectuer des ajustements.<\/p>\n\n<h2>Une approche globale des performances de NGINX : d'autres leviers d'optimisation<\/h2>\n\n<p>En plus de <strong>sendfile<\/strong> Il est avantageux de d\u00e9finir correctement le nombre de `worker_processes` et de `worker_connections` afin de ne pas limiter artificiellement les sockets. Sous Linux, j\u2019utilise epoll et je m\u2019assure de disposer d\u2019un nombre suffisant de descripteurs de fichiers pour \u00e9viter que les pics de charge n\u2019entra\u00eenent des goulots d\u2019\u00e9tranglement. Pour les contenus textuels, j\u2019active gzip ou Brotli et je v\u00e9rifie si le niveau de compression sollicite le processeur de mani\u00e8re raisonnable. Au niveau de la couche de transport, je maintiens les connexions ouvertes plus longtemps et j\u2019optimise le Keep-Alive, comme l\u2019explique le guide <a href=\"https:\/\/webhosting.de\/fr\/http-keep-alive-reglage-charge-du-serveur-optimisation-des-performances-flux\/\">R\u00e9glage Keep Alive<\/a> fournit des indications pratiques. Le protocole TLS, la r\u00e9utilisation des sessions et les protocoles HTTP\/2 ou HTTP\/3 compl\u00e8tent la configuration et permettent un haut niveau de parall\u00e9lisme avec une latence mod\u00e9r\u00e9e.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx_performance_4203.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Limites et cas particuliers : TLS, HTTP\/2\/3 et utilisation d'un proxy<\/h2>\n\n<p>Je tiens compte du fait que <strong>sendfile<\/strong> ne s'applique techniquement qu'aux chemins d'acc\u00e8s aux fichiers non chiffr\u00e9s ou \u00e0 certaines fonctions sp\u00e9cifiques du noyau. Avec le protocole TLS classique, NGINX chiffre les octets dans l'espace utilisateur, ce qui annule l'avantage du \u00ab zero-copy \u00bb ; les noyaux modernes peuvent partiellement d\u00e9porter le chiffrement vers le noyau, ce qui r\u00e9tablit cet effet, mais cette fonctionnalit\u00e9 n'est pas disponible dans toutes les configurations. Dans le cas de <strong>HTTP\/2<\/strong> les donn\u00e9es sont contenues dans des trames, plusieurs r\u00e9ponses partagent une connexion TCP et NGINX r\u00e9organise activement les octets : dans ce cas, sendfile est moins pertinent. <strong>HTTP\/3<\/strong> repose sur UDP\/QUIC et suit \u00e0 nouveau d'autres r\u00e8gles, de sorte que j'obtiens plut\u00f4t des gains d'efficacit\u00e9 gr\u00e2ce \u00e0 des tampons, au contr\u00f4le de la congestion et \u00e0 des tailles de chunks correctement choisies. En tant que <strong>Proxy inverse<\/strong> sendfile ne s'applique que lorsque je sers effectivement des fichiers provenant du syst\u00e8me de fichiers local ; r\u00e9ponses tir\u00e9es de <em>proxy_pass<\/em> ou <em>fastcgi_pass<\/em> passent de toute fa\u00e7on par l'espace utilisateur. C'est pourquoi je s\u00e9pare strictement les ressources du chemin dynamique, afin de tirer pleinement parti du mode \u00ab zero-copy \u00bb.<\/p>\n\n<h2>Bien comprendre la compression : gzip\/Brotli ou gzip_static<\/h2>\n\n<p>D\u00e8s que NGINX compresse du contenu \u00e0 la vol\u00e9e, il doit lire le fichier, le traiter et \u00e9crire le r\u00e9sultat \u2013 ce qui entra\u00eene une perte de <strong>sendfile<\/strong> son avantage. Pour les ressources statiques, j'utilise donc, dans la mesure du possible, <em>pr\u00e9-compress\u00e9s<\/em> fichiers (par exemple .gz ou .br) et les fais servir directement. Cela permet de conserver le chemin \u00ab zero-copy \u00bb, car NGINX peut transmettre le fichier pr\u00e9-compress\u00e9 comme n\u2019importe quelle autre ressource. Pour les contenus riches en texte et rarement modifi\u00e9s, cela me permet de r\u00e9aliser des \u00e9conomies de CPU et d\u2019obtenir un d\u00e9bit stable, sans perte de temps de transfert. Pour les fichiers binaires et les formats d\u00e9j\u00e0 compress\u00e9s, j\u2019\u00e9vite toute compression \u00e0 l\u2019ex\u00e9cution : ici, seul le d\u00e9bit d\u2019E\/S compte, et les fonctions `sendfile` et `tcp_nopush` montrent tout leur potentiel.<\/p>\n\n<h2>AIO, directio et Page Cache : mod\u00e8les pour les petits et les grands fichiers<\/h2>\n\n<p>Je combine <strong>sendfile<\/strong> avec des E\/S asynchrones et un acc\u00e8s direct au disque, afin d'obtenir les meilleures performances en fonction de la taille des fichiers. Les fichiers de petite \u00e0 moyenne taille b\u00e9n\u00e9ficient du cache de pages du noyau et restent sur le chemin sendfile. En revanche, les tr\u00e8s gros fichiers peuvent saturer le cache ; dans ce cas, je les lis de mani\u00e8re cibl\u00e9e avec <em>directio<\/em> en dehors du cache et j'utilise des threads AIO. Cela permet de soulager la m\u00e9moire et de maintenir une faible latence pour les autres requ\u00eates. Voici \u00e0 quoi ressemble un mod\u00e8le typique :<\/p>\n\n<pre><code>http {\n    # Chemin standard : Zero-Copy \u00e0 partir du cache de pages\n    sendfile on;\n    tcp_nopush on;\n    tcp_nodelay on;\n\n # Fichiers volumineux : contournement du cache et lecture asynchrone\n    aio threads;\n    directio 4m ; # ne s'applique qu'aux fichiers &gt;= 4 MiB\n    output_buffers 1 512k ;    # Tampons pour les chemins directio\n    sendfile_max_chunk 1m ;    # \u00c9quit\u00e9 sous forte charge\n}\n<\/code><\/pre>\n\n<p>Gr\u00e2ce \u00e0 cette hi\u00e9rarchisation, les petits fichiers restent extr\u00eamement efficaces, tandis que les transferts de tr\u00e8s grande taille ne saturent pas la m\u00e9moire vive. Important : directio d\u00e9sactive le chemin sendfile pour les fichiers concern\u00e9s \u2013 c'est exactement ce que je souhaite pour le cas d'utilisation des fichiers volumineux.<\/p>\n\n<h2>\u00c9quit\u00e9 et contr\u00f4le du d\u00e9bit sous charge<\/h2>\n\n<p>Pendant les p\u00e9riodes de forte charge, je souhaite \u00e9viter qu'un seul flux ne monopolise le processeur ou le socket. J'utilise <strong>sendfile_max_chunk<\/strong>, afin que NGINX renvoie le noyau apr\u00e8s un nombre d\u00e9fini d'octets et laisse de la place \u00e0 d'autres connexions. Pour le contr\u00f4le de la bande passante, les \u00e9l\u00e9ments suivants sont utiles : <em>limit_rate<\/em> et <em>limit_rate_after<\/em>, par exemple pour limiter les t\u00e9l\u00e9chargements en masse tout en garantissant la fluidit\u00e9 des \u00e9l\u00e9ments de l'interface utilisateur. Avec <em>postpone_output<\/em> Je contr\u00f4le \u00e0 partir de quelle taille de r\u00e9ponse NGINX commence l'envoi ; en combinaison avec tcp_nopush, je garantis ainsi un d\u00e9coupage propre des paquets. De plus, je veille \u00e0 ce que <em>lingering_close<\/em>, afin que les paquets restants puissent \u00eatre transmis correctement et que la connexion ne soit pas interrompue brusquement.<\/p>\n\n<h2>Syst\u00e8mes de fichiers, lecture anticip\u00e9e et chemins d'acc\u00e8s au stockage<\/h2>\n\n<p>Parce que <strong>sendfile<\/strong> Lorsqu'on utilise les caches de page, le syst\u00e8me de fichiers sous-jacent joue un r\u00f4le important. Je v\u00e9rifie les valeurs de pr\u00e9lecture et je les r\u00e8gle de mani\u00e8re \u00e0 ce que les lectures s\u00e9quentielles de fichiers volumineux ne soient pas ralenties, sans pour autant \u00e9vincer les ressources plus petites. Sur <em>ext4<\/em> ou <em>xfs<\/em> J'observe \u00e0 quel point le pr\u00e9chargement et le planificateur d'E\/S s'adaptent bien \u00e0 mon profil de d\u00e9bit. Sur les syst\u00e8mes de fichiers r\u00e9seau (NFS\/SMB), je teste rigoureusement les valeurs rsize\/wsize, la mise en cache et les latences, car m\u00eame de l\u00e9gers \u00e9carts suffisent \u00e0 neutraliser l'avantage du \u00ab zero-copy \u00bb. Ma r\u00e8gle reste la m\u00eame : exploiter au maximum les chemins locaux dans un premier temps, puis ajuster prudemment les piles externes \u2013 et toujours privil\u00e9gier les mesures objectives plut\u00f4t que l'intuition.<\/p>\n\n<h2>Adapter de mani\u00e8re pragmatique la pile r\u00e9seau et le d\u00e9chargement de la carte r\u00e9seau<\/h2>\n\n<p>Pour les nombres \u00e9lev\u00e9s de connexions, je m'en remets \u00e0 l'ajustement automatique des tampons des piles modernes, mais j'ajuste les tampons d'\u00e9mission et de r\u00e9ception si n\u00e9cessaire. Les fonctions de d\u00e9chargement des cartes r\u00e9seau (NIC) telles que TSO, GSO et GRO r\u00e9duisent sensiblement la charge du processeur ; je proc\u00e8de toutefois \u00e0 des v\u00e9rifications minutieuses lors des mesures, car les captures de paquets peuvent \u00eatre fauss\u00e9es par le d\u00e9chargement (apparence d'un nombre r\u00e9duit de segments tr\u00e8s volumineux). C'est pourquoi je corr\u00e8le <em>pcap<\/em>\u2011Traces avec des m\u00e9triques issues de NGINX et du noyau, afin de distinguer les tailles r\u00e9elles des paquets des artefacts li\u00e9s \u00e0 l'offload. En cas de pics de latence, j'interromps bri\u00e8vement les tests en d\u00e9sactivant l'offload, je consigne la diff\u00e9rence observ\u00e9e, puis je d\u00e9termine ce qui est le plus avantageux en fonctionnement continu.<\/p>\n\n<h2>Mod\u00e8les de configuration par site : activation et d\u00e9sactivation cibl\u00e9es<\/h2>\n\n<p>Je me r\u00e9serve la possibilit\u00e9 de, <strong>sendfile<\/strong> \u00e0 remplacer en fonction du chemin ou du type de fichier. Pour les r\u00e9pertoires statiques, cette option reste activ\u00e9e ; pour les chemins de streaming ou dynamiques, je la d\u00e9sactive de mani\u00e8re s\u00e9lective lorsque la m\u00e9moire tampon ou les filtres (par exemple, la compression) ont la priorit\u00e9. Voici un petit exemple :<\/p>\n\n<pre><code>server {\n    listen 80;\n    server_name static.example.com;\n    root \/var\/www\/static;\n\n # Ressources statiques : Zero-Copy\n    location \/assets\/ {\n sendfile on;\n tcp_nopush on;\n        tcp_nodelay on;\n expires 7d;\n    }\n\n # Contenu dynamique ou streaming : la flexibilit\u00e9 prime sur le \u00ab Zero-Copy \u00bb\n    location \/api\/ {\n sendfile off;\n proxy_pass http:\/\/app_upstream;\n    }\n}\n<\/code><\/pre>\n\n<p>Cette s\u00e9paration m'\u00e9vite de perdre des avantages d'un c\u00f4t\u00e9 simplement parce qu'un autre parcours impose des exigences particuli\u00e8res.<\/p>\n\n<h2>Range, Slices et grands catalogues<\/h2>\n\n<p>Dans le cas de grands projets, <strong>gamme<\/strong>-Requests met en avant ses atouts : le client ne charge que les parties n\u00e9cessaires, et les connexions restent stables. Dans les catalogues de contenu contenant des fichiers tr\u00e8s volumineux, j\u2019aime segmenter les transferts de mani\u00e8re logique : la charge du serveur est r\u00e9partie plus uniform\u00e9ment, et les erreurs telles que les interruptions prennent moins de temps. Dans les sc\u00e9narios de mise en cache, je pr\u00e9viens les \u201e thundering herds \u201c en mettant en m\u00e9moire tampon les r\u00e9ponses de mani\u00e8re judicieuse, sans toutefois retenir artificiellement les petits blocs et les donn\u00e9es restantes. L\u2019interaction avec tcp_nopush reste ici essentielle : je conserve des segments initiaux volumineux, mais je ne laisse pas la fin attendre.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx-performance-5678.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Strat\u00e9gie de mesure et d'essai : d\u00e9montrer de mani\u00e8re fiable les effets<\/h2>\n\n<p>Je valide les optimisations \u00e0 l'aide de tests reproductibles. C\u00f4t\u00e9 serveur, j'observe les profils d'utilisation du processeur, <em>$request_time<\/em>, <em>1 TP 4 To envoy\u00e9s<\/em>, les connexions actives et les changements de contexte. Sur le r\u00e9seau, je mesure la taille des segments, les retransmissions et la distribution des RTT ; je corr\u00e8le les captures de paquets avec les statistiques des sockets afin de prendre en compte les effets de d\u00e9chargement. C\u00f4t\u00e9 client, je compare le TTFB, le First Contentful Paint et les temps de t\u00e9l\u00e9chargement avec des RTT et des bandes passantes r\u00e9alistes. Je fais varier la MTU, les param\u00e8tres Keep-Alive et la taille des fichiers afin de ne pas me limiter aux courbes \u00ab best-case \u00bb. Au final, je d\u00e9termine, \u00e0 l\u2019aide de chiffres concrets, si sendfile\/tcp_nopush offrent la stabilit\u00e9 et l\u2019efficacit\u00e9 souhait\u00e9es pour la charge de travail concern\u00e9e \u2013 et j\u2019affine les r\u00e9glages jusqu\u2019\u00e0 ce que ce soit le cas.<\/p>\n\n<h2>Les d\u00e9tails HTTP qui font la diff\u00e9rence : Range et streaming<\/h2>\n\n<p>J'utilise <strong>gamme<\/strong>-Requ\u00eates pour les fichiers volumineux, afin que les clients ne rechargent que les parties n\u00e9cessaires et que les connexions restent stables. Notamment dans le cas des avances vid\u00e9o et de la reprise des mises \u00e0 jour, une prise en charge efficace des plages d'octets permet de r\u00e9partir le d\u00e9bit de mani\u00e8re optimale ; vous trouverez des informations compl\u00e9mentaires sur la page consacr\u00e9e \u00e0 <a href=\"https:\/\/webhosting.de\/fr\/http-range-requests-media-and-download-hosting-performance-byte\/\">Requ\u00eates HTTP de type \u00ab range \u00bb<\/a>. Pour les r\u00e9ponses continues dont le corps ne cesse de s'allonger, je teste des strat\u00e9gies de streaming et veille \u00e0 ce que les tampons ne conservent pas involontairement les donn\u00e9es trop longtemps. Ce faisant, je respecte les caches et d\u00e9finis des en-t\u00eates pertinents afin que les proxys et les navigateurs se comportent correctement. Je tiens compte de l\u2019interaction avec `tcp_nopush`, car la taille des paquets et le moment du vidage ont une influence directe sur la rapidit\u00e9 per\u00e7ue.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx-performance-5678.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>En bref<\/h2>\n\n<p>Avec <strong>sendfile<\/strong> Je transmets efficacement les fichiers directement au noyau, et gr\u00e2ce \u00e0 `tcp_nopush`, je veille \u00e0 ce que les paquets soient correctement remplis avant qu'ils n'encombrent la ligne. Ces deux directives se compl\u00e8tent, tandis que `tcp_nodelay` transmet le dernier octet restant sans d\u00e9lai. Je v\u00e9rifie l\u2019effet en conditions de trafic r\u00e9el, en pr\u00eatant attention au chemin d\u2019acc\u00e8s au stockage, \u00e0 la MTU, au Keep-Alive et \u00e0 la compression, et j\u2019effectue des mesures syst\u00e9matiques. Pour les charges de travail de type WordPress et CDN, les avantages se font particuli\u00e8rement vite sentir, car de nombreuses requ\u00eates concernent des ressources statiques. En utilisant ces param\u00e8tres de mani\u00e8re cibl\u00e9e, on obtient un d\u00e9bit plus \u00e9lev\u00e9 par c\u0153ur, on r\u00e9duit la surcharge et on cr\u00e9e des r\u00e9serves pour faire face aux v\u00e9ritables pics de croissance.<\/p>","protected":false},"excerpt":{"rendered":"<p>Guide pratique sur la configuration des options \u00ab sendfile \u00bb et \u00ab tcp_nopush \u00bb de NGINX pour optimiser les performances lors de la diffusion de fichiers statiques et de t\u00e9l\u00e9chargements volumineux.<\/p>","protected":false},"author":1,"featured_media":20899,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20906","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-webserver-plesk-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"157","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"nginx sendfile","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20899","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20906","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/comments?post=20906"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20906\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/20899"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=20906"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=20906"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=20906"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}