{"id":21459,"date":"2026-09-16T15:03:59","date_gmt":"2026-09-16T13:03:59","guid":{"rendered":"https:\/\/webhosting.de\/nginx-keepalive-requests-optimieren-webserver-performance-tuning\/"},"modified":"2026-09-16T15:03:59","modified_gmt":"2026-09-16T13:03:59","slug":"ottimizzazione-delle-richieste-keepalive-di-nginx-ottimizzazione-delle-prestazioni-del-server-web","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/nginx-keepalive-requests-optimieren-webserver-performance-tuning\/","title":{"rendered":"Ottimizzazione delle richieste Keepalive di NGINX: massime prestazioni del server web grazie a una messa a punto mirata"},"content":{"rendered":"<p>Con <strong>nginx keepalive<\/strong> Riduco i costi di instaurazione della connessione, diminuisco gli handshake e accelero sensibilmente i tempi di risposta. Timeout mirati, limiti di richieste per connessione e socket upstream riutilizzati garantiscono miglioramenti misurabili delle prestazioni senza bisogno di nuovo hardware.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<ul>\n  <li><strong>Timeout<\/strong> Scegliere con criterio: il tempo di inattivit\u00e0 deve essere il pi\u00f9 breve possibile, ma abbastanza lungo da essere utile.<\/li>\n  <li><strong>Richieste<\/strong> Limitare per connessione: socket a lunga durata, nessun blocco.<\/li>\n  <li><strong>Pool a monte<\/strong> Attiva: connessioni persistenti al backend per ogni worker.<\/li>\n  <li><strong>Lavoratore<\/strong> e ottimizzare le connessioni: slot sufficienti per i client inattivi e quelli attivi.<\/li>\n  <li><strong>Monitoraggio<\/strong> Configurare: monitorare la velocit\u00e0 di connessione, la latenza e gli errori.<\/li>\n<\/ul>\n\n<h2>NGINX Keepalive: effetti e costi<\/h2>\n\n<p>Lascio intenzionalmente aperte le connessioni TCP perch\u00e9 <strong>Strette di mano<\/strong> sono costose e prevalgono in presenza di molte piccole richieste. I socket persistenti non solo riducono i tempi di andata e ritorno (RTT), ma livellano anche il carico della CPU, poich\u00e9 la crittografia per TLS viene avviata meno frequentemente. Tuttavia, ogni connessione aperta occupa <strong>Risorse<\/strong>, come i descrittori di file e i buffer, che devo tenere d\u2019occhio. Il segreto sta nel giusto equilibrio: riutilizzo sufficiente per garantire la velocit\u00e0, risorse sufficienti per creare nuove connessioni nei momenti di picco di carico. Chi riesce a trovare questo equilibrio ottiene valori TTFB costantemente bassi e un\u2019esperienza utente fluida.<\/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\/09\/nginx-keepalive-optimierung-4271.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>HTTP\/2 e HTTP\/3: il multiplexing incontra il keepalive<\/h2>\n\n<p>Con <strong>HTTP\/2<\/strong> e <strong>HTTP\/3<\/strong> Il numero di connessioni necessarie per ogni client diminuisce, poich\u00e9 pi\u00f9 flussi passano attraverso un\u2019unica linea. Il keepalive rimane comunque importante: una connessione dovrebbe rimanere aperta in modo affidabile, altrimenti il vantaggio del multiplexing viene vanificato dalle frequenti riconnessioni.<\/p>\n<p>Presto attenzione ai parametri di inattivit\u00e0 specifici per i protocolli moderni e mi assicuro che i valori siano compatibili con i timeout del mio client. Per i test, inizio con valori moderati e li aumento, una volta che il carico si \u00e8 stabilizzato, finch\u00e9 il tasso di riconnessione non diminuisce e le latenze rimangono costanti.<\/p>\n\n<pre><code>http {\n    # HTTP\/2: tempo di inattivit\u00e0 per gli stream inattivi ma aperti\n    http2_idle_timeout 60s;\n\n    # HTTP\/3\/QUIC: logica simile per le connessioni basate su UDP\n    http3_idle_timeout 60s;\n\n    # La ripresa della sessione TLS riduce i costi dell'handshake nelle nuove connessioni\n    ssl_session_cache shared:SSL:50m;\n    ssl_session_timeout 1d;\n    ssl_session_tickets off;\n}\n<\/code><\/pre>\n\n<p>Il multiplexing riduce il numero necessario di connessioni TCP\/QUIC parallele, ma non l'importanza della <strong>timeout corretti<\/strong>. Chi utilizza HTTP\/2\/3 pu\u00f2 spesso impostare i timeout del client in modo un po\u2019 pi\u00f9 generoso, poich\u00e9 molte piccole risorse transitano attraverso lo stesso canale. Importante: rimanere misurabili <em>Tempo al primo byte<\/em>, tassi di errore e flussi aperti per ogni connessione.<\/p>\n\n<h2>Configurare correttamente il client keepalive<\/h2>\n\n<p>Per i client browser, gestisco il riutilizzo tramite <strong>keepalive_timeout<\/strong> e <strong>keepalive_requests<\/strong>, affinch\u00e9 i socket rimangano attivi abbastanza a lungo senza rimanere bloccati all\u2019infinito. Come punto di partenza utilizzo un timeout di 30\u201360 secondi e 100\u2013300 richieste per connessione, poi regolo i valori in base alle metriche. Una classificazione dettagliata \u00e8 fornita da questo <a href=\"https:\/\/webhosting.de\/it\/http-keepalive-timeout-configurazione-delle-prestazioni-del-server\/\">Guida al timeout di keepalive<\/a>, che spiega l'impatto sulla latenza e sulle risorse del server. I timeout pi\u00f9 brevi sono indicati in caso di un numero molto elevato di richieste brevi, mentre quelli pi\u00f9 lunghi sono utili per gli accessi periodici all'API. Per iniziare, imposto valori predefiniti chiari e misuro l'effetto sulle connessioni aperte e sui tipi di errore.<\/p>\n\n<pre><code>http {\n    # Connessioni inattive con il client\n    keepalive_timeout 60s;\n    # Limite massimo di richieste per connessione TCP\n    keepalive_requests 200;\n\n    # Opzionale: disabilitare il Keep-Alive per determinati client (bug legacy)\n    # keepalive_disable msie6;\n}\n<\/code><\/pre>\n\n<h2>Keepalive a monte nel proxy inverso<\/h2>\n\n<p>Tra NGINX e le applicazioni backend utilizzo socket upstream persistenti, poich\u00e9 la connessione a PHP-FPM, Node.js o ai servizi Python avviene anch\u2019essa <strong>Latenza<\/strong> costa. A tal fine, attivo nel pool upstream un numero adeguato di connessioni riutilizzabili per ogni worker. \u00c8 importante che l\u2019HTTP\/1.1 sia impostato verso il backend e che l\u2019header Connection sia vuoto; altrimenti, la richiesta \u201eclose\u201c del client interrompe la persistenza del backend. Mi baso sul numero di richieste simultanee e configuro il pool in modo che non si verifichino quasi mai nuove connessioni. In questo modo si riduce il tempo di connessione al backend e l\u2019intera catena garantisce prestazioni pi\u00f9 fluide <strong>Risposte<\/strong>.<\/p>\n\n<pre><code>upstream backend {\n    server 127.0.0.1:9000;\n    keepalive 64; # Numero di connessioni upstream persistenti per worker\n}\n\nserver {\n    location \/ {\n proxy_pass http:\/\/backend;\n        proxy_http_version 1.1;\n proxy_set_header Connection \"\";\n # Keepalive TCP per i socket upstream a livello di sistema operativo\n proxy_socket_keepalive on;\n    }\n}\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx_optimierung_miniature_4891.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Dimensionamento della piscina e budget per i collegamenti<\/h2>\n\n<p>Calcolo i pool in modo realistico: il numero di connessioni upstream persistenti risulta da <strong>worker_processes \u00d7 keepalive<\/strong> per ogni upstream. Chi utilizza 8 worker e un valore di keepalive pari a 64 mantiene aperti fino a 512 socket per ogni upstream \u2013 per ogni istanza. Se si utilizza un bilanciatore di carico o si hanno pi\u00f9 destinazioni upstream, il numero pu\u00f2 aumentare rapidamente.<\/p>\n<p>Il mio obiettivo: un numero sufficiente di socket aperti affinch\u00e9 la maggior parte delle richieste <em>senza il nuovo Connect<\/em> viene soddisfatta, ma rimane ancora margine per picchi di traffico. Monitoro la metrica \u201enuove connessioni upstream al secondo\u201c e la riduco fino a quando ulteriori aumenti delle dimensioni del pool non comportano pi\u00f9 miglioramenti significativi della latenza.<\/p>\n<p>Tengo anche conto di <strong>Equit\u00e0<\/strong>: I pool troppo grandi possono penalizzare i client appena arrivati, poich\u00e9 gli slot dei worker occupano le connessioni inattive. Un limite moderato, abbinato a un monitoraggio attivo, \u00e8 solitamente pi\u00f9 efficace rispetto a valori massimi fissati a caso.<\/p>\n\n<h2>Messa a punto: timeout e limiti di richiesta<\/h2>\n\n<p>Combino il timeout e il limite di richieste in modo tale che le connessioni vengano effettivamente riutilizzate senza arrivare al <strong>Sciatore di fondo<\/strong> . Valori elevati su entrambi gli assi riducono al minimo i \u201cconnects\u201d, ma aumentano il rischio di socket bloccati in caso di problemi di rete. Valori bassi garantiscono connessioni fresche, ma comportano handshake aggiuntivi. Procedo a piccoli passi, osservo gli errori e effettuo aggiustamenti a intervalli regolari. La tabella seguente mostra intervalli iniziali ragionevoli per diversi modelli di utilizzo e fornisce una sintesi <strong>Orientamento<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Scenario<\/th>\n      <th>keepalive_timeout<\/th>\n      <th>keepalive_requests<\/th>\n      <th>Suggerimento<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Molte visualizzazioni brevi delle pagine<\/td>\n      <td>10\u201330 s<\/td>\n      <td>100-300<\/td>\n      <td>Reuse veloce, basso consumo in modalit\u00e0 idle<\/td>\n    <\/tr>\n    <tr>\n      <td>Sito web tipico<\/td>\n      <td>60\u2013120 s<\/td>\n      <td>200\u2013400<\/td>\n      <td>Buona media per gli asset e l'HTML<\/td>\n    <\/tr>\n    <tr>\n      <td>API con chiamate periodiche<\/td>\n      <td>60\u2013120 s<\/td>\n      <td>300\u20131000<\/td>\n      <td>Tasso di riutilizzo pi\u00f9 elevato per i clienti<\/td>\n    <\/tr>\n    <tr>\n      <td>Servizi interni \/ Gateway<\/td>\n      <td>30\u201390 s<\/td>\n      <td>500\u20131000+<\/td>\n      <td>La costanza \u00e8 pi\u00f9 importante dei \u201cconnects\u201d minimi<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Ottimizzazione dei worker e connessioni<\/h2>\n\n<p>Ho messo <strong>processi_lavoratori<\/strong> su \"auto\" o sul numero di core della CPU e assicurati di pianificare una quantit\u00e0 sufficiente <strong>connessioni_lavoratore<\/strong> perch\u00e9 i socket inattivi occupano degli slot. Limiti troppo bassi impediscono l\u2019accettazione di nuove connessioni, anche se sarebbe ancora disponibile capacit\u00e0 della CPU. Chi utilizza pool di keepalive di grandi dimensioni necessita di un numero sufficiente di descrittori e slot di evento per ogni worker. Una buona introduzione \u00e8 fornita da \u201e<a href=\"https:\/\/webhosting.de\/it\/nginx-connessioni-dei-worker-scalabilita-di-migliaia-di-richieste-aumento-del-traffico\/\">Scalabilit\u00e0 di Worker-Connections<\/a>\u201c, che illustra le relazioni tra eventi, connessioni e carico. Valori ben ponderati garantiscono che il riutilizzo in stato di inattivit\u00e0 e le nuove connessioni possano coesistere.<\/p>\n\n<pre><code>worker_processes auto;\n\nevents {\n    worker_connections 4096;\n    # Opzionale: reuseport pu\u00f2 migliorare la distribuzione a livello di kernel\n    # multi_accept on;\n}\n\nhttp {\n    keepalive_timeout 60s;\n    keepalive_requests 200;\n\n upstream backend {\n server 127.0.0.1:9000;\n keepalive 64;\n    }\n}\n<\/code><\/pre>\n\n<h2>Ottimizzazione del sistema operativo e dei socket<\/h2>\n\n<p>Sto verificando i limiti di sistema affinch\u00e9 Keepalive possa esprimere appieno il proprio potenziale. Un numero insufficiente di descrittori o code di socket troppo strette causano <strong>colli di bottiglia artificiali<\/strong>. Oltre a ulimit e worker_rlimit_nofile, anche i limiti del kernel sono determinanti.<\/p>\n\n<pre><code># Valori sysctl di esempio (da modificare con cautela e dopo aver effettuato dei test)\nfs.file-max = 1000000\nnet.core.somaxconn = 65535\nnet.core.netdev_max_backlog = 16384\nnet.ipv4.ip_local_port_range = 1024 65000\nnet.ipv4.tcp_fin_timeout = 15\nnet.ipv4.tcp_tw_reuse = 1\nnet.ipv4.tcp_max_syn_backlog = 262144\n<\/code><\/pre>\n\n<p>Adatto questi valori al contesto: molte connessioni di breve durata traggono vantaggio da un intervallo di porte pi\u00f9 ampio e da tempi FIN\/TIME_WAIT ridotti. Per quanto riguarda il keepalive upstream, riduco <em>Neuconnects<\/em>, il che riduce i picchi di TIME_WAIT. Inoltre, tengo conto di <strong>NAT<\/strong>-Dispositivi tra proxy e backend: i timeout di inattivit\u00e0 troppo aggressivi nella rete interrompono le connessioni in modo imprevedibile. \u00c8 consigliabile impostare un limite moderato di richieste per socket e utilizzare i keepalive TCP (<code>proxy_socket_keepalive on;<\/code>) prevengono le connessioni \u201estale\u201c.<\/p>\n\n<h2>Impostare correttamente l'intestazione e la versione HTTP<\/h2>\n\n<p>Presto attenzione a <strong>HTTP\/1.1<\/strong> sul backend, perch\u00e9 Upstream-Keepalive funziona solo in questo modo. Inoltre, rimuovo la gestione attiva delle connessioni tramite header, in modo che NGINX gestisca autonomamente la persistenza. Sul lato client, lascio che Keep-Alive funzioni in conformit\u00e0 con lo standard e ne limito la durata tramite timeout e limite di richieste. Inoltre, controllo i timeout di inattivit\u00e0 del backend e li imposto a un valore leggermente superiore rispetto a quello di NGINX, per evitare errori di reset. Header ben strutturate garantiscono la <strong>Riutilizzo<\/strong> senza chiusure indesiderate.<\/p>\n\n<pre><code>Esempio #: proxy con header corretti\nlocation \/api\/ {\n    proxy_pass http:\/\/backend;\n    proxy_http_version 1.1;\n    proxy_set_header Connection \"\";\n}\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-keepalive-optimization-7123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Differenza: HTTP Keep-Alive vs. TCP Keep-Alive<\/h2>\n\n<p>Faccio una distinzione rigorosa tra <strong>HTTP Keep-Alive<\/strong> (pi\u00f9 richieste HTTP per connessione) e <strong>TCP-Conservazione<\/strong> (Probe a livello di sistema operativo per individuare i terminali inattivi). Gestisco l'HTTP Keep-Alive con <code>keepalive_timeout<\/code> e <code>keepalive_requests<\/code>, mentre i keepalive TCP, a seconda dello stack, tramite <code>proxy_socket_keepalive on;<\/code> e i parametri di sistema. Per i backend che operano su reti instabili, attivo i keepalive TCP per liberare pi\u00f9 rapidamente i socket bloccati.<\/p>\n\n<h2>Processo a lunga durata e casi particolari: WebSockets, SSE, gRPC<\/h2>\n\n<p>I WebSocket e gli eventi inviati dal server sono <strong>Sciatore di fondo<\/strong>, che mantengono aperta una connessione per un lungo periodo \u2013 in questo caso il classico Reuse ha un ruolo secondario. Mi occupo di trovare soluzioni adeguate <code>proxy_read_timeout<\/code> e proteggimi con <code>send_timeout<\/code> contro <em>Slowloris<\/em>-Effetti. Per gRPC (basato su HTTP\/2) valgono le considerazioni relative al multiplexing; imposto i timeout di inattivit\u00e0 in modo tale che gli stream non vengano chiusi inutilmente.<\/p>\n\n<pre><code>location \/ws\/ {\n    proxy_pass http:\/\/backend;\n    proxy_http_version 1.1;\n    proxy_set_header Upgrade $http_upgrade;\n    proxy_set_header Connection \"upgrade\";\n    proxy_read_timeout 300s;\n    send_timeout 30s;\n}\n<\/code><\/pre>\n\n<h2>Monitoraggio e metriche<\/h2>\n\n<p>Misuro il successo attraverso indicatori quali il tasso di nuove connessioni upstream, <strong>tempo_di_connessione_a_stream<\/strong> e la percentuale di connessioni aperte per ogni worker. Un calo dei tassi di connessione a parit\u00e0 o aumento delle richieste indica un riutilizzo efficace. Timeout anomali o reset delle connessioni segnalano incongruenze nei timeout tra NGINX e il backend. Inoltre, monitoro la memoria, i descrittori di file e le code degli eventi sotto carico. Chi effettua controlli regolari individua tempestivamente le tendenze ed evita costose <strong>Fallimenti<\/strong>.<\/p>\n\n<h2>Miglioramenti alla registrazione per una maggiore trasparenza sul riutilizzo<\/h2>\n\n<p>Per avere un quadro pi\u00f9 chiaro, aggiungo i dettagli di connessione al log di Access. In questo modo posso capire con quale frequenza viene riutilizzata una connessione TCP e come si evolvono i tempi di connessione.<\/p>\n\n<pre><code>log_format keepalive_fmt\n  '$remote_addr $host \"$request\" $status $body_bytes_sent '\n  '$request_time $upstream_connect_time '\n  'conn:$connection reqs:$connection_requests';\n\naccess_log \/var\/log\/nginx\/access_keepalive.log keepalive_fmt;\n<\/code><\/pre>\n\n<p>Sto osservando i valori mediani e P95\/P99 di <em>tempo_di_connessione_a_stream<\/em> nonch\u00e9 la distribuzione di <em>$_richieste_di_connessione<\/em>. Un aumento del numero di Reuse a parit\u00e0 di latenza indica che i pool e i timeout sono stati impostati correttamente.<\/p>\n\n<h2>Ostacoli e soluzioni tipiche<\/h2>\n\n<p>Le pool troppo grandi occupano gli slot di connessione mentre i nuovi client rimangono in attesa, per questo mantengo le dimensioni moderate e le regolo con attenzione. Timeout di inattivit\u00e0 diversi tra il proxy e il backend causano reset, quindi imposto il timeout del backend a un valore leggermente superiore rispetto a <strong>NGINX<\/strong>. Un \u201eConnection: close\u201c dimenticato nell'intestazione del proxy interrompe la persistenza, pertanto svuoto sistematicamente l'intestazione. La negoziazione TLS pu\u00f2 sovraccaricare la CPU in caso di numerose nuove connessioni, problema che risolvo aumentando la percentuale di riutilizzo. In caso di errori di rete sporadici, \u00e8 utile impostare un limite moderato di richieste per socket, in modo che le vecchie <strong>Sessioni<\/strong> non vivere per sempre.<\/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\/09\/nginx_keepalive_optimierung_4723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Configurazioni orientate alla pratica<\/h2>\n\n<p>Per i siti web molto frequentati, scelgo un timeout breve e un limite di richieste medio-alto, in modo che le risorse funzionino in modo efficiente. Nel caso di API con chiamate ricorrenti, aumento il limite per ridurre ulteriormente gli handshake TCP e TLS. Dimensiono i pool upstream in base al parallelismo previsto ed eseguo test con traffico realistico. Ogni ambiente si comporta in modo diverso, pertanto dopo ogni modifica verifico la latenza e i profili di errore. Due esempi illustrano <strong>valori iniziali<\/strong>, che poi affino utilizzando delle metriche.<\/p>\n\n<pre><code># Scenario 1: sito web molto frequentato\nhttp {\n    keepalive_timeout 30s;\n    keepalive_requests 300;\n\n upstream app {\n server 127.0.0.1:8080;\n        keepalive 32;\n    }\n\n server {\n listen 443 ssl http2;\n Monitoraggio del tempo di inattivit\u00e0 HTTP\/2 (#)\n http2_idle_timeout 45s;\n    }\n}\n<\/code><\/pre>\n\n<pre><code># Scenario 2: API con chiamate periodiche\nhttp {\n    keepalive_timeout 75s;\n    keepalive_requests 1000;\n\n    upstream api_backend {\n    server 127.0.0.1:9001;\n    keepalive 64;\n    }\n\n    server {\n listen 443 ssl http2;\n # Finestra di inattivit\u00e0 leggermente pi\u00f9 lunga per le chiamate ricorrenti\n http2_idle_timeout 75s;\n    }\n}\n<\/code><\/pre>\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\/09\/serverraum-nginx-3721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Lista di controllo per l'ottimizzazione iterativa<\/h2>\n\n<p>Inizio con un\u2019analisi dello status quo: i modelli di traffico, i tempi di risposta e il tasso di errore dettano il ritmo. Successivamente, imposto il timeout del client e il limite di richieste su valori iniziali affidabili e attivo i pool upstream. Impostiamo i timeout di inattivit\u00e0 del backend a valori leggermente superiori rispetto a quelli di NGINX, in modo da evitare che si verifichino <strong>Reset<\/strong> si verificano. Successivamente monitoro il numero di connessioni, il tempo di connessione e i socket aperti per ogni worker. Chi desidera approfondire il concetto di riutilizzo trover\u00e0 spunti su <a href=\"https:\/\/webhosting.de\/it\/riutilizzo-della-connessione-http-keepalive-ottimizzazione-serverperf-boost\/\">Riutilizzo delle connessioni<\/a> e limiti massimi ragionevoli.<\/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\/09\/nginx_keepalive_opt_5731.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Diagnosi aggiuntiva: discrepanze e comportamento temporale<\/h2>\n\n<p>Quando le connessioni si interrompono apparentemente \u201esenza motivo\u201c, cerco <strong>Discordanze<\/strong> nella catena: inattivit\u00e0 del client vs. timeout di NGINX vs. inattivit\u00e0 del backend e NAT\/gateway intermedi. Aumento leggermente il timeout del backend oltre il valore di NGINX, controllo i codici di reset nel log degli errori e osservo se <em>tempo_di_connessione_a_stream<\/em> mostra picchi. Spesso \u00e8 sufficiente un piccolo margine (ad es. +10\u201320%) nel timeout del backend per eliminare i reset.<\/p>\n<p>Faccio inoltre notare che \u201e<em>lingering close<\/em>\u201cFasi \u201c-\u201d: durante la chiusura, NGINX lascia scorrere brevemente i dati in entrata, occupando risorse dei worker. Un numero molto elevato di chiusure simultanee pu\u00f2 bloccare gli eventi. In questi casi, calibro le finestre temporali di chiusura e mantengo sotto controllo il numero totale di connessioni aperte impostando valori di keepalive adeguati.<\/p>\n\n<h2>Sintesi: il keepalive come leva per migliorare le prestazioni<\/h2>\n\n<p>Utilizzo Keepalive in modo mirato perch\u00e9 riduce i costi di instaurazione della connessione, diminuisce la latenza e alleggerisce il carico sulla CPU. La combinazione di un timeout adeguato, un limite di richieste ben definito e pool upstream adeguati porta a notevoli <strong>Velocit\u00e0<\/strong>. Senza monitoraggio, il potenziale rimane inutilizzato; per questo motivo controllo costantemente gli indicatori e ne adeguo i valori passo dopo passo. Chi ha bisogno di risorse aggiuntive deve prestare attenzione al numero di worker, agli slot di connessione e alla corretta gestione delle intestazioni. Configurazioni professionali, ad esempio nel caso di <strong>webhoster.de<\/strong>, sfruttano appieno queste possibilit\u00e0 di regolazione e forniscono servizi rapidi e affidabili.<\/p>","protected":false},"excerpt":{"rendered":"<p>Scopri come ottimizzare le richieste keepalive di NGINX per migliorare notevolmente le prestazioni del tuo server web. Con impostazioni pratiche per keepalive_timeout, keepalive_requests, keepalive upstream e la messa a punto dei worker, con particolare attenzione al keepalive di NGINX come fattore chiave.<\/p>","protected":false},"author":1,"featured_media":21452,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-21459","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":"108","_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 keepalive","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":"21452","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21459","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=21459"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21459\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/21452"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=21459"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=21459"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=21459"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}