{"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-guida-alle-prestazioni-configurazione","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/nginx-sendfile-tcp-nopush-ratgeber-performance-setup\/","title":{"rendered":"Utilizzo corretto di sendfile e tcp_nopush in NGINX per ottenere le massime prestazioni"},"content":{"rendered":"<p>Con <strong>nginx sendfile<\/strong> e <strong>tcp_nopush<\/strong> Trasmetto i file statici in modalit\u00e0 zero-copy dal file system al socket, riducendo cos\u00ec in modo tangibile sia il carico della CPU che il numero di pacchetti. Se configurate correttamente, entrambe le direttive aumentano l'efficienza della trasmissione, riducono l'overhead e gettano le basi per un'ottimizzazione efficace di nginx per quanto riguarda le risorse e i download.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<ul>\n  <li><strong>Copia zero<\/strong> tramite sendfile: meno copie, maggiore velocit\u00e0 di trasmissione<\/li>\n  <li><strong>tcp_nopush<\/strong> memorizza i pacchetti: frame pi\u00f9 grandi, meno overhead<\/li>\n  <li><strong>Combinazione<\/strong> conta: sendfile + tcp_nopush + tcp_nodelay<\/li>\n  <li><strong>Casi d'uso<\/strong> dare priorit\u00e0 a: risorse statiche, download di grandi dimensioni<\/li>\n  <li><strong>Test<\/strong> per NFS\/SMB: misurare l'effetto, se necessario disattivare sendfile<\/li>\n<\/ul>\n\n<h2>Perch\u00e9 sendfile migliora cos\u00ec tanto le prestazioni di NGINX<\/h2>\n\n<p>Attivo <strong>sendfile<\/strong>, poich\u00e9 il kernel \u00e8 in grado di inviare i file direttamente tramite lo stack di rete, senza dover ricorrere a ulteriori operazioni di copia nello spazio utente. Questo percorso \u201czero-copy\u201d riduce i cambi di contesto e risparmia cicli di CPU, soprattutto quando molti client contemporanei recuperano contenuti statici. I file di grandi dimensioni come immagini, CSS, JavaScript o archivi ne traggono vantaggio, poich\u00e9 il trasferimento dei dati avviene in modo pi\u00f9 uniforme e con un overhead minore. Anche le cache di sistema risultano pi\u00f9 efficienti, poich\u00e9 si verificano meno movimenti di memoria e il kernel controlla il percorso dei dati. Il vantaggio \u00e8 pi\u00f9 evidente sui file system locali, motivo per cui effettuo le misurazioni innanzitutto l\u00ec, prima di estenderle a configurazioni pi\u00f9 particolari.<\/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>Cosa fa esattamente tcp_nopush e in quali casi d\u00e0 il meglio di s\u00e9<\/h2>\n\n<p>Con <strong>tcp_nopush<\/strong> Chiedo al sistema di inviare i pacchetti TCP solo quando sono riempiti in modo sensato, invece di inviare segmenti piccoli troppo presto. Su Linux ci\u00f2 corrisponde a TCP_CORK, su FreeBSD a TCP_NOPUSH, e in entrambi i casi il numero di pacchetti diminuisce in modo misurabile. La direttiva non riduce la latenza al minimo, ma mira a ottenere un miglior rapporto tra dati utili e overhead. Utilizzo tcp_nopush in modo mirato per i file statici, poich\u00e9 \u00e8 proprio in questo contesto che i flussi di dati contigui garantiscono i maggiori guadagni in termini di efficienza. Senza sendfile, tcp_nopush rimane inefficace, pertanto integro sempre entrambe le impostazioni insieme.<\/p>\n\n<h2>sendfile e tcp_nopush in coppia: ecco come imposto le basi<\/h2>\n\n<p>La combinazione di <strong>sendfile<\/strong> e tcp_nopush riduce le copie e raggruppa i pacchetti, consentendo cos\u00ec a un server per ogni core della CPU di gestire un numero significativamente maggiore di trasferimenti paralleli. Configuro entrambi a livello di contesto http e spesso aggiungo tcp_nodelay, affinch\u00e9 l\u2019ultima parte di un flusso venga inviata senza tempi di attesa. Rimane importante effettuare test con traffico reale, poich\u00e9 le dimensioni dei pacchetti, l\u2019MTU e i client variano e l\u2019equilibrio ottimale pu\u00f2 differire leggermente a seconda del carico di lavoro. Per le directory statiche \u00e8 solitamente sufficiente l\u2019attivazione globale, mentre nel caso di percorsi di risposta dinamici prendo in considerazione l\u2019effetto che ne deriva. Questa combinazione fornisce una solida base per ulteriori passaggi di ottimizzazione di nginx, che verranno aggiunti in seguito.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>direttiva<\/th>\n      <th>Scopo<\/th>\n      <th>Effetto tipico<\/th>\n      <th>Dipendenza<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>sendfile on<\/strong><\/td>\n      <td>Zero-Copy da file a socket<\/td>\n      <td>Minore carico della CPU, maggiore produttivit\u00e0<\/td>\n      <td>Sistema di file locale ideale<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>tcp_nopush on<\/strong><\/td>\n      <td>Riempire i pacchi, ridurre i costi generali<\/td>\n      <td>Meno segmenti per file<\/td>\n      <td>Funziona solo con sendfile<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>tcp_nodelay on<\/strong><\/td>\n      <td>Invia gli ultimi byte senza attendere<\/td>\n      <td>Rapida conclusione del trasferimento<\/td>\n      <td>Aggiunto 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>Ecco come tcp_nodelay interagisce con tcp_nopush<\/h2>\n\n<p>Attivo <strong>tcp_nopush<\/strong>, per inviare l'inizio di un trasferimento in pacchetti pi\u00f9 grandi, e abilito contemporaneamente tcp_nodelay affinch\u00e9 la conclusione non rimanga bloccata. Entrambe le impostazioni agiscono su fasi diverse del flusso e non si ostacolano a vicenda quando NGINX distribuisce i file tramite sendfile. Soprattutto in presenza di molti file di piccole dimensioni, tcp_nodelay impedisce che il client attenda inutilmente a causa di piccoli dati residui. Testo prima la combinazione in ambiente di staging, osservo gli RTT e le dimensioni dei segmenti e li confronto con le metriche live. In questo modo garantisco l\u2019efficienza all\u2019inizio e la velocit\u00e0 alla fine del trasferimento.<\/p>\n\n<pre><code>http {\n    sendfile on;\n    tcp_nopush on;\n    tcp_nodelay on;\n}\n<\/code><\/pre>\n\n<h2>Scenari di applicazione tipici: dove le direttive hanno un forte impatto<\/h2>\n\n<p>Per i grandi <strong>Scaricamento<\/strong> Come nel caso di video, archivi o immagini ISO, il percorso zero-copy del kernel riduce notevolmente il tempo di CPU per ogni trasferimento. In configurazioni simili a CDN con numerosi file CSS, JS e di font, tcp_nopush riduce il numero di segmenti, aumentando cos\u00ec la larghezza di banda utilizzabile per ogni socket. Sui siti WordPress con una buona cache, la maggior parte delle richieste riguarda risorse statiche, motivo per cui ne vedo l\u2019effetto molto rapidamente. Anche gli artefatti di build, le immagini dei container o i programmi di installazione ne traggono vantaggio, a condizione che si trovino in locale e non passino attraverso un file system di rete instabile. Chi si aspetta picchi di carico, con questa coppia di strumenti otterr\u00e0 la massima stabilit\u00e0 dall\u2019hardware a disposizione.<\/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>Esempio pratico: NGINX per WordPress con caching e risorse<\/h2>\n\n<p>Nelle configurazioni di WordPress imposto <strong>sendfile<\/strong>, imposta tcp_nopush e tcp_nodelay a livello globale, servo le risorse statiche direttamente e mantengo una netta separazione tra PHP-FPM e i percorsi dinamici. Aggiungo header di cache appropriati per immagini, CSS e JavaScript, in modo che i browser generino un minor numero di roundtrip. Quando fornisco risposte di tipo streaming, prendo in considerazione l\u2019interazione con il buffering e verifico come le dimensioni dei chunk influiscano sulla latenza e sulla velocit\u00e0 di trasmissione; a questo proposito \u00e8 utile la panoramica su <a href=\"https:\/\/webhosting.de\/it\/risposta-http-streaming-hosting-performance-chunks\/\">Streaming della risposta in pezzi<\/a>. Per i contenuti testuali ricorro alla compressione, senza comprimere inutilmente i file binari. In questo modo il flusso delle richieste rimane stabile, la CPU non viene sovraccaricata e il tempo di risposta (Time-to-First-Byte) \u00e8 breve.<\/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>Quando disattivo intenzionalmente la funzione sendfile<\/h2>\n\n<p>Accendo <strong>sendfile<\/strong> quando i file si trovano su NFS, SMB o sistemi di file distribuiti, che nel mio test hanno registrato velocit\u00e0 di trasferimento inferiori. Alcuni driver o latenze nel percorso di archiviazione annullano il vantaggio dello Zero Copy, motivo per cui le misurazioni sono determinanti. In caso di anomalie sporadiche della rete, disattivo innanzitutto tcp_nopush per circoscrivere gli effetti, prima di mettere in discussione sendfile stesso. Anche bug insoliti del kernel o stack obsoleti possono essere motivi per passare temporaneamente al classico percorso di lettura-scrittura. \u00c8 importante apportare le modifiche in modo graduale e documentarle con metriche.<\/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>Fonti di errore che tengo d\u2019occhio<\/h2>\n\n<p>Per prima cosa verifico se <strong>tcp_nopush<\/strong> \u00e8 attivata per errore, mentre sendfile rimane disattivato, poich\u00e9 in tal caso l\u2019impostazione non ha alcun effetto. Per i percorsi dinamici, osservo se un buffering aggiuntivo aumenta la latenza e valuto i vantaggi rispetto al tempo di risposta. Nelle reti ad alta latenza, valuto se pacchetti pi\u00f9 grandi siano davvero d\u2019aiuto o se sia necessario ottimizzare le dimensioni dei segmenti e il keep-alive. Anche la configurazione dell\u2019MTU e le funzionalit\u00e0 di offloading della scheda di rete possono influire visibilmente sul risultato. Log chiari, campioni pcap e metriche di sistema correlate mi indicano rapidamente dove intervenire.<\/p>\n\n<h2>Un approccio olistico alle prestazioni di NGINX: ulteriori parametri di regolazione<\/h2>\n\n<p>Inoltre <strong>sendfile<\/strong> \u00c8 importante impostare il numero corretto di `worker_processes` e `worker_connections`, in modo da non limitare artificialmente i socket. Su Linux utilizzo epoll e mi assicuro che ci siano abbastanza descrittori di file, affinch\u00e9 i picchi di carico non causino colli di bottiglia. Per i contenuti testuali attivo gzip o Brotli e verifico se il livello di compressione grava in modo ragionevole sulla CPU. A livello di trasporto mantengo aperte le connessioni pi\u00f9 a lungo e ottimizzo il Keep-Alive, come indicato nella guida <a href=\"https:\/\/webhosting.de\/it\/http-keep-alive-ottimizzazione-carico-server-ottimizzazione-prestazioni-flusso\/\">Ottimizzazione Keep-Alive<\/a> fornisce indicazioni pratiche. TLS, il riutilizzo delle sessioni e HTTP\/2 o HTTP\/3 completano la configurazione e garantiscono un elevato livello di parallelismo con una latenza moderata.<\/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>Limiti e casi particolari: TLS, HTTP\/2\/3 e proxy<\/h2>\n\n<p>Tengo conto del fatto che <strong>sendfile<\/strong> tecnicamente si applica solo ai percorsi dei file non crittografati o a specifiche funzioni del kernel. Nel TLS classico, NGINX crittografa i byte nello spazio utente, il che elimina il vantaggio dello zero-copy; i kernel moderni possono in parte spostare la crittografia nel kernel, ripristinando cos\u00ec tale vantaggio, ma questa funzionalit\u00e0 non \u00e8 disponibile in tutte le configurazioni. In <strong>HTTP\/2<\/strong> i dati sono contenuti in frame, pi\u00f9 risposte condividono una connessione TCP e NGINX ricompone attivamente i byte: in questo caso, sendfile \u00e8 meno rilevante. <strong>HTTP\/3<\/strong> si basa su UDP\/QUIC e segue regole ancora diverse, per cui ottengo miglioramenti in termini di efficienza soprattutto grazie ai buffer, al controllo della congestione e a dimensioni dei chunk scelte correttamente. Come <strong>Proxy inverso<\/strong> sendfile viene utilizzato solo quando servo effettivamente file dal file system locale; le risposte da <em>proxy_pass<\/em> oppure <em>fastcgi_pass<\/em> passano comunque attraverso lo spazio utente. Per questo motivo separo rigorosamente le risorse dal percorso dinamico, in modo da sfruttare al massimo l\u2019approccio zero-copy.<\/p>\n\n<h2>Comprendere correttamente la compressione: gzip\/Brotli contro gzip_static<\/h2>\n\n<p>Quando NGINX comprime i contenuti al volo, deve leggere il file, elaborarlo e scrivere il risultato; in questo processo si verifica una perdita di <strong>sendfile<\/strong> il suo vantaggio. Per le risorse statiche, quindi, utilizzo, ove possibile, <em>precompressi<\/em> File (ad es. .gz o .br) e li faccio consegnare direttamente. In questo modo si mantiene il percorso zero-copy, poich\u00e9 NGINX pu\u00f2 trasmettere il file precompresso come qualsiasi altra risorsa. Per i contenuti prevalentemente testuali e modificati raramente, in questo modo ottengo un risparmio di CPU e un throughput stabile, senza compromettere i tempi di trasmissione. Nel caso di file binari e formati gi\u00e0 compressi, evito qualsiasi compressione in fase di esecuzione: in questo caso conta esclusivamente la velocit\u00e0 di trasmissione I\/O, ed \u00e8 qui che sendfile e tcp_nopush danno il meglio di s\u00e9.<\/p>\n\n<h2>AIO, directio e Page Cache: modelli per file di piccole e grandi dimensioni<\/h2>\n\n<p>Combino <strong>sendfile<\/strong> con I\/O asincrono e accesso diretto al disco, per ottenere le prestazioni ottimali a seconda delle dimensioni del file. I file di piccole e medie dimensioni traggono vantaggio dalla cache di pagina del kernel e rimangono sul percorso sendfile. I file molto grandi, invece, possono sovrascrivere la cache; in tal caso, li leggo in modo mirato con <em>direzione<\/em> al di fuori della cache e utilizzo thread AIO. In questo modo alleggerisco il carico sulla memoria e mantengo bassa la latenza per le altre richieste. Un modello tipico si presenta cos\u00ec:<\/p>\n\n<pre><code>http {\n    # Percorso predefinito: zero-copy dalla cache di pagina\n    sendfile on;\n    tcp_nopush on;\n    tcp_nodelay on;\n\n # File di grandi dimensioni: lettura asincrona senza passare dalla cache\n    aio threads;\n    directio 4m; # si applica solo per file &gt;= 4 MiB\n    output_buffers 1 512k;    # buffer per percorsi directio\n    sendfile_max_chunk 1m;    # equit\u00e0 sotto carico elevato\n}\n<\/code><\/pre>\n\n<p>Grazie a questa scalabilit\u00e0, gli asset di piccole dimensioni rimangono estremamente efficienti, mentre i trasferimenti di grandi dimensioni non sovraccaricano la memoria di lavoro. Importante: directio disattiva il percorso sendfile per i file interessati \u2013 ed \u00e8 proprio quello che intendo per il caso d'uso dei file di grandi dimensioni.<\/p>\n\n<h2>Equit\u00e0 e controllo del flusso sotto carico<\/h2>\n\n<p>Nei periodi di carico elevato, vorrei evitare che un singolo flusso monopolizzi la CPU o il socket. Impostare <strong>sendfile_max_chunk<\/strong>, in modo che NGINX restituisca il kernel dopo un numero definito di byte e lasci spazio ad altre connessioni. Per la gestione della larghezza di banda sono utili <em>limit_rate<\/em> e <em>tasso_limite_dopo<\/em>, ad esempio per limitare i download in blocco, mentre le risorse dell\u2019interfaccia utente rimangono veloci. Con <em>postpone_output<\/em> impostando la dimensione minima della risposta a partire dalla quale NGINX inizia l'invio; in combinazione con tcp_nopush, garantisco cos\u00ec un frazionamento corretto dei pacchetti. Inoltre, mi assicuro che <em>lingering_close<\/em>, in modo che i pacchetti rimanenti possano essere trasmessi correttamente e il socket non venga chiuso bruscamente.<\/p>\n\n<h2>Sistemi di file, readahead e percorsi di archiviazione<\/h2>\n\n<p>Perch\u00e9 <strong>sendfile<\/strong> Quando si utilizzano le cache di pagina, il file system sottostante riveste un ruolo fondamentale. Controllo i valori di readahead e li mantengo in modo tale che le operazioni di lettura sequenziale di file di grandi dimensioni non subiscano rallentamenti, senza per\u00f2 sacrificare le risorse pi\u00f9 piccole. Su <em>ext4<\/em> oppure <em>xfs<\/em> Osservo quanto il prefetching e lo scheduler I\/O si adattino bene al mio modello di throughput. Sui file system di rete (NFS\/SMB) sottopongo a test rigorosi rsize\/wsize, la cache e le latenze, poich\u00e9 anche piccole variazioni neutralizzano il vantaggio dello zero-copy. La mia regola rimane: sfruttare al massimo i percorsi locali, poi regolare con cautela gli stack esterni \u2013 e dare sempre la precedenza ai valori misurati rispetto all\u2019intuizione.<\/p>\n\n<h2>Ottimizzare in modo pragmatico lo stack di rete e l'offloading della scheda di rete<\/h2>\n\n<p>Per un numero elevato di connessioni mi affido alla regolazione automatica dei buffer degli stack moderni, ma se necessario regolo i buffer di trasmissione e ricezione. Le operazioni di offload della scheda di rete (NIC), come TSO, GSO e GRO, riducono sensibilmente il carico della CPU; tuttavia, durante le misurazioni procedo con cautela, poich\u00e9 le acquisizioni dei pacchetti possono risultare distorte dall\u2019offload (apparentemente pochi segmenti di dimensioni molto grandi). Pertanto, metto in correlazione <em>pcap<\/em>\u2011Traces con metriche provenienti da NGINX e dal kernel, per distinguere le dimensioni effettive del traffico dagli artefatti dell\u2019offload. In caso di picchi di latenza, interrompo brevemente i test disattivando gli offload, documento la differenza e poi decido quale soluzione sia pi\u00f9 vantaggiosa nel funzionamento continuo.<\/p>\n\n<h2>Modelli di configurazione per ogni sede: attivazione e disattivazione mirate<\/h2>\n\n<p>Mi riservo la possibilit\u00e0 di, <strong>sendfile<\/strong> da sovrascrivere a seconda del percorso o del tipo di file. Per le directory statiche rimane attivo, mentre per i percorsi in streaming o dinamici lo disattivo in modo selettivo quando i buffer o i filtri (ad es. la compressione) hanno la priorit\u00e0. Ecco un breve esempio:<\/p>\n\n<pre><code>server {\n    listen 80;\n    server_name static.example.com;\n    root \/var\/www\/static;\n\n # Risorse statiche: Zero-Copy\n    location \/assets\/ {\n sendfile on;\n tcp_nopush on;\n        tcp_nodelay on;\n expires 7d;\n    }\n\n # Contenuti dinamici o streaming: flessibilit\u00e0 prima di Zero-Copy\n    location \/api\/ {\n sendfile off;\n proxy_pass http:\/\/app_upstream;\n    }\n}\n<\/code><\/pre>\n\n<p>Questa separazione mi impedisce di perdere i vantaggi da un lato, solo perch\u00e9 un altro percorso prevede requisiti specifici.<\/p>\n\n<h2>Intervalli, sezioni e cataloghi di grandi dimensioni<\/h2>\n\n<p>Nel caso di immobili di grandi dimensioni, si applica <strong>Gamma<\/strong>-Le richieste ne sfruttano i punti di forza: il client carica solo le parti necessarie e le connessioni rimangono stabili. Nei cataloghi di contenuti con file di grandi dimensioni, preferisco segmentare logicamente i trasferimenti: il carico sul server si distribuisce in modo pi\u00f9 uniforme e gli errori, come le interruzioni, comportano una perdita di tempo minore. Negli scenari di caching prevengo i \u201ethundering herds\u201c bufferizzando le risposte in modo ragionevole, senza per\u00f2 trattenere artificialmente piccoli blocchi e dati residui. L\u2019interazione con tcp_nopush rimane fondamentale in questo contesto: mantengo grandi i segmenti iniziali, ma non faccio attendere quelli finali.<\/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>Strategia di misurazione e collaudo: dimostrare gli effetti in modo attendibile<\/h2>\n\n<p>Corropo le ottimizzazioni con test riproducibili. A livello di server, monitoro i profili della CPU, <em>$request_time<\/em>, <em>1 TP 4 TB inviati<\/em>, connessioni attive e cambi di contesto. In rete misuro le dimensioni dei segmenti, le ritrasmissioni e la distribuzione degli RTT; metto in correlazione le acquisizioni dei pacchetti con le statistiche dei socket per tenere conto degli effetti dell\u2019offload. Sul lato client confronto TTFB, First Contentful Paint e tempi di download in condizioni realistiche di RTT e larghezza di banda. Vario MTU, impostazioni Keep-Alive e dimensioni dei file, in modo da non vedere solo curve di scenario ottimale. Infine, sulla base di dati concreti, valuto se sendfile\/tcp_nopush garantiscono la stabilit\u00e0 e l\u2019efficienza desiderate nel carico di lavoro in questione e procedo a una regolazione fine fino a quando non raggiungono tali risultati.<\/p>\n\n<h2>Dettagli HTTP che fanno la differenza: Range e streaming<\/h2>\n\n<p>Uso <strong>Gamma<\/strong>-Richieste per file di grandi dimensioni, in modo che i client scarichino solo le parti necessarie e le connessioni rimangano stabili. Soprattutto in caso di riproduzione video in anticipo e ripresa degli aggiornamenti, un supporto efficiente degli intervalli di byte aiuta a distribuire in modo ottimale la larghezza di banda; ulteriori informazioni sono disponibili alla pagina dedicata a <a href=\"https:\/\/webhosting.de\/it\/richieste-di-gamma-http-prestazioni-di-hosting-media-e-download-byte\/\">Richieste HTTP Range<\/a>. Per le risposte continue con un corpo sempre pi\u00f9 lungo, sto testando strategie di streaming e mi assicuro che i buffer non trattengano i dati involontariamente per troppo tempo. Nel farlo, rispetto le cache e imposto header appropriate affinch\u00e9 i proxy e i browser agiscano correttamente. Prendo in considerazione l\u2019interazione con tcp_nopush, poich\u00e9 le dimensioni dei pacchetti e la tempistica del flush influenzano direttamente la velocit\u00e0 percepita.<\/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>Riassumendo brevemente<\/h2>\n\n<p>Con <strong>sendfile<\/strong> Inoltro i file in modo efficiente direttamente al kernel e, con tcp_nopush, faccio in modo che i pacchetti vengano riempiti in modo ottimale prima che appesantiscano la linea. Entrambe le direttive si completano a vicenda, mentre tcp_nodelay invia l\u2019ultimo byte rimanente senza ritardi. Verifico l\u2019effetto con traffico reale, prestando attenzione al percorso di archiviazione, all\u2019MTU, al keep-alive e alla compressione, ed effettuo misurazioni sistematiche. Per i carichi di lavoro di tipo WordPress e CDN, i benefici si manifestano particolarmente in fretta, poich\u00e9 molte richieste riguardano risorse statiche. Chi utilizza queste impostazioni in modo mirato ottiene una maggiore larghezza di banda per core, riduce l\u2019overhead e crea riserve per i veri picchi di crescita.<\/p>","protected":false},"excerpt":{"rendered":"<p>Guida pratica alla configurazione delle opzioni `sendfile` e `tcp_nopush` di NGINX per ottenere le massime prestazioni nella distribuzione di file statici e download di grandi dimensioni.<\/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":"136","_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\/it\/wp-json\/wp\/v2\/posts\/20906","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/comments?post=20906"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20906\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/20899"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=20906"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=20906"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=20906"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}