{"id":18056,"date":"2026-03-03T18:23:49","date_gmt":"2026-03-03T17:23:49","guid":{"rendered":"https:\/\/webhosting.de\/http-keepalive-timeout-server-performance-konfiguration\/"},"modified":"2026-03-03T18:23:49","modified_gmt":"2026-03-03T17:23:49","slug":"http-keepalive-timeout-configurazione-delle-prestazioni-del-server","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/http-keepalive-timeout-server-performance-konfiguration\/","title":{"rendered":"Timeout HTTP Keep-Alive: configurazione ottimale per le prestazioni del server"},"content":{"rendered":"<p>Con l'attenzione rivolta a <strong>Timeout HTTP Keep-Alive<\/strong> Vi mostrer\u00f2 come impostare i tempi di inattivit\u00e0 in modo da riutilizzare le connessioni senza bloccare i thread. Spiegher\u00f2 i valori specifici, mostrer\u00f2 le insidie tipiche e fornir\u00f2 configurazioni provate e testate per <strong>nginx<\/strong>, Apache e il sistema operativo.<\/p>\n\n<h2>Punti centrali<\/h2>\n<ul>\n  <li><strong>Equilibrio<\/strong>Troppo breve aumenta le strette di mano, troppo lungo blocca i thread.<\/li>\n  <li><strong>Valori<\/strong>Per lo pi\u00f9 5-15 s e 100-500 richieste per connessione.<\/li>\n  <li><strong>Coordinamento<\/strong>Coordinare i timeout di client, LB e firewall.<\/li>\n  <li><strong>Casi speciali<\/strong>WebSockets, SSE, Polling lungo separatamente.<\/li>\n  <li><strong>Monitoraggio<\/strong>Monitorare i socket aperti, gli FD e le latenze.<\/li>\n<\/ul>\n\n<h2>HTTP Keep-Alive spiegato brevemente<\/h2>\n<p>Mantengo le connessioni TCP con <strong>Mantenere in vita<\/strong> in modo che diverse richieste utilizzino la stessa linea. In questo modo si risparmiano ripetuti handshake TCP e TLS e si riducono i tempi di attesa. <strong>CPU<\/strong>-in modo considerevole. Ci\u00f2 \u00e8 particolarmente vantaggioso per molti file di piccole dimensioni, come icone, JSON o CSS. Ogni nuova connessione evitata riduce gli scambi di contesto e alleggerisce le routine del kernel. Nei benchmark con un'alta percentuale di GET, la durata complessiva si riduce significativamente perch\u00e9 vengono generati meno pacchetti SYN\/ACK e pi\u00f9 tempo di calcolo passa alla logica dell'applicazione.<\/p>\n<p>Misuro rapidamente l'effetto: le latenze medie mobili diventano pi\u00f9 uniformi e il numero di nuove connessioni TCP al secondo diminuisce. Non ottengo questo risultato per magia, ma grazie a <strong>Riutilizzo della connessione<\/strong> e limiti ragionevoli. \u00c8 importante che Keep-Alive non sostituisca il rendering veloce o la cache. Riduce i tempi di attesa al confine della rete, mentre l'applicazione stessa deve continuare a rispondere in modo efficiente. Entrambi insieme aumentano il <strong>Prestazioni<\/strong> in modo evidente.<\/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\/03\/server-optimierung-4721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Capire il giusto timeout<\/h2>\n<p>Il timeout definisce il tempo in cui una connessione inattiva rimane aperta prima che il server la chiuda. <strong>chiude<\/strong>. Se lo imposto troppo corto, i client aprono continuamente nuove connessioni TCP, il che <strong>Spese generali<\/strong> viene alzato. Se lo imposto troppo a lungo, le connessioni inattive parcheggiano lavoratori o thread preziosi. L'arte sta nell'equilibrio tra riutilizzo e consumo di risorse. Faccio dei test pratici: prima lo imposto in modo approssimativo, poi lo metto a punto con dei test di carico.<\/p>\n<p>Presto anche attenzione alla relazione tra i tempi di risposta e le finestre di inattivit\u00e0. Se l'interazione tipica dell'utente tra due clic \u00e8 di 2-4 secondi, un timeout di 5-15 secondi di solito copre il modello reale. Le chiamate API brevi possono tollerare facilmente 5-10 secondi, i carichi di lavoro multimediali 10-15 secondi. \u00c8 importante non esagerare: timeout eccessivamente lunghi raramente portano a un aumento dei tempi di inattivit\u00e0. <strong>Produttivit\u00e0<\/strong>, ma spesso portano al blocco <strong>Risorse<\/strong>. Lo riconosco subito dal numero crescente di prese aperte e dai numeri elevati di FD.<\/p>\n\n<h2>Separare in modo pulito i tipi di timeout<\/h2>\n<p>Faccio una netta distinzione tra <strong>Timeout inattivit\u00e0<\/strong> (Keep-Alive), <strong>Timeout lettura\/intestazione<\/strong> (quanto tempo il server attende le richieste in arrivo) e <strong>Timeout invio\/scrittura<\/strong> (per quanto tempo \u00e8 tollerato l'invio verso il cliente). Queste categorie svolgono compiti diversi:<\/p>\n<ul>\n  <li><strong>Timeout di inattivit\u00e0:<\/strong> Controlla il riutilizzo e la durata del parcheggio delle connessioni inattive.<\/li>\n  <li><strong>Timeout lettura\/intestazione:<\/strong> Protegge dai client lenti (slow lorise) e dalle intestazioni inviate a met\u00e0.<\/li>\n  <li><strong>Timeout di invio\/scrittura:<\/strong> Evita che il server attenda all'infinito per una ricezione lenta da parte del client.<\/li>\n<\/ul>\n<p>All'indirizzo <strong>nginx<\/strong> Uso deliberatamente header_timeout\/read_timeout e send_timeout per contesto (http\/server\/location) oltre a keepalive_timeout. Dalle nuove versioni ho impostato opzionalmente <strong>tempo_di_tenuta<\/strong>, per limitare la durata massima di una connessione, anche se rimane attiva. In <strong>Apache<\/strong> Uso anche <strong>RichiestaReadTimeout<\/strong> (mod_reqtimeout) e controllare <strong>Timeout<\/strong> (globale) separato da <strong>KeepAliveTimeout<\/strong>. Questa separazione \u00e8 un elemento importante per evitare di vincolare le risorse senza alcun beneficio reale.<\/p>\n\n<h2>Valori consigliati nella pratica<\/h2>\n<p>Per gli ambienti produttivi, ho impostato un timeout di keep-alive di 5-15 secondi e 100-500 richieste per connessione. Questo intervallo consente di ottenere buoni tassi di riutilizzo delle connessioni e di mantenere basso il numero di connessioni inattive. Su <strong>nginx<\/strong> Uso keepalive_timeout 10s come valore iniziale e keepalive_requests 200. Se c'\u00e8 molto traffico, lo aumento moderatamente se vedo troppe nuove connessioni TCP. Se il traffico \u00e8 scarso, lo abbasso di nuovo per evitare una marea di traffico inattivo.<\/p>\n<p>Chi va pi\u00f9 a fondo beneficer\u00e0 di un chiaro processo di messa a punto con punti di misura. A tal fine, riassumo le mie linee guida in una guida pratica che descrive il percorso dalla misurazione alla configurazione al controllo. Per un inizio rapido, vi rimando ai miei passi in <a href=\"https:\/\/webhosting.de\/it\/http-keep-alive-ottimizzazione-carico-server-ottimizzazione-prestazioni-flusso\/\">Ottimizzazione Keep-Alive<\/a>. Come controllare <strong>Riutilizzo<\/strong> e limiti ed evitare sorprese. Alla fine, ci\u00f2 che conta \u00e8 una bassa latenza con una stabilit\u00e0 <strong>Produttivit\u00e0<\/strong>.<\/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\/03\/http-keep-alive-optimierung-1723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Rischi di timeout prolungati<\/h2>\n<p>Un timeout lungo mantiene le connessioni artificiali <strong>aperto<\/strong> e blocca i lavoratori anche se non segue alcuna richiesta. Questo causa l'ingrossamento dei socket e l'aumento del numero di descrittori di file. Se il processo raggiunge i suoi limiti, vedo rifiutare errori di accettazione o code quando si stabilisce una connessione. La memoria cresce, i garbage collector o gli allocatori costano pi\u00f9 tempo e la latenza aumenta. In caso di errore, i client inviano a socket che sono gi\u00e0 chiusi e ricevono messaggi criptici <strong>Errore<\/strong>.<\/p>\n<p>Lo evito impostando valori moderati e controllando regolarmente le metriche. Se le connessioni inattive aumentano troppo in condizioni di basso carico, abbasso il timeout. Se vedo molte nuove connessioni al secondo durante i picchi di traffico, lo aumento attentamente a piccoli passi. In questo modo mantengo il <strong>Capacit\u00e0<\/strong> utilizzabili e prevenire le connessioni morte. Il risultato \u00e8 un sistema pi\u00f9 fluido e con meno <strong>Suggerimenti<\/strong> nelle curve.<\/p>\n\n<h2>Configurazione: nginx, Apache e livello OS<\/h2>\n<p>Inizio dal livello del server web e imposto il timeout e i limiti. Su <strong>nginx<\/strong> Imposto keepalive_timeout 5-15s e keepalive_requests 100-500. In Apache con event-MPM combino KeepAlive On, KeepAliveTimeout 5-15 e MaxKeepAliveRequests 100-500. Poi calibro i pool di worker o di thread in base al carico previsto. In questo modo si evita che i keep-alive inattivi diventino produttivi. <strong>Slot machine<\/strong> legare.<\/p>\n<p>Aumento i limiti e le code a livello di sistema operativo. Imposto ulimit -n ad almeno 100.000, regolo net.core.somaxconn e tcp_max_syn_backlog e controllo la gestione di TIME_WAIT. In questo modo si garantisce che il kernel e il processo abbiano a disposizione abbastanza <strong>Risorse<\/strong> fornire. Infine, verifico i percorsi dalla NIC tramite il bilanciamento IRQ all'applicazione. Questo mi consente di riconoscere tempestivamente i colli di bottiglia e di mantenere la <strong>Latenza<\/strong> basso.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Componente<\/th>\n      <th>Direttiva\/Impostazione<\/th>\n      <th>Raccomandazione<\/th>\n      <th>Suggerimento<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>nginx<\/td>\n      <td>keepalive_timeout<\/td>\n      <td>5\u201315 s<\/td>\n      <td><strong>Pi\u00f9 breve<\/strong> con poco traffico, pi\u00f9 lungo con molte piccole richieste<\/td>\n    <\/tr>\n    <tr>\n      <td>nginx<\/td>\n      <td>keepalive_requests<\/td>\n      <td>100\u2013500<\/td>\n      <td>Ricicla i composti e riduce <strong>Perdite<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Apache (evento)<\/td>\n      <td>KeepAliveTimeout<\/td>\n      <td>5\u201315 s<\/td>\n      <td>Event-MPM gestisce l'inattivit\u00e0 in modo pi\u00f9 efficiente rispetto a <strong>prefork<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Sistema operativo<\/td>\n      <td>ulimit -n<\/td>\n      <td>\u2265 100.000<\/td>\n      <td>Pi\u00f9 FD aperti per molti <strong>Prese<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Sistema operativo<\/td>\n      <td>net.core.somaxconn<\/td>\n      <td>Aumento<\/td>\n      <td>Meno connessioni rifiutate sotto <strong>Carico di picco<\/strong><\/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\/03\/server-optimization-http-keep-alive-4317.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Proxy inverso e riutilizzo a monte<\/h2>\n<p>Penso sempre a keep-alive <strong>end-to-end<\/strong>. Dietro l'edge server c'\u00e8 spesso una catena di reverse proxy \u2192 app server. Per nginx, attivo il mio <strong>Piscine Keep Alive<\/strong> (upstream keepalive, keepalive_requests, keepalive_timeout), impostare proxy_http_version 1.1 e rimuovere \u201eConnection: close\u201c. Questo mi fa anche risparmiare <em>interno<\/em> e scaricare i backend delle applicazioni (Node.js, Java, PHP-FPM). In Apache con mod_proxy, mantengo anche connessioni persistenti ai server di backend e le limito per destinazione, in modo che un hotspot non monopolizzi i pool.<\/p>\n<p>Misuro separatamente: tasso di riutilizzo Client\u2192Edge e Edge\u2192Backend. Se vedo un buon riutilizzo all'edge, ma molte nuove connessioni al backend, aumento selettivamente i pool upstream. Questo mi permette di scalare senza aumentare globalmente i timeout del frontend.<\/p>\n\n<h2>Lavoratori, thread e limiti del sistema operativo<\/h2>\n<p>Non dimensiono i lavoratori, gli eventi e i thread in base ai valori desiderati, ma in base a <strong>profilo di carico<\/strong>. A tal fine, monitoro le richieste attive, i lavoratori inattivi, l'utilizzo del ciclo degli eventi e i passaggi di contesto. Se i thread sono parcheggiati in modalit\u00e0 idle, abbasso il timeout o i limiti massimi di idle per thread. Se vedo sempre il 100% della CPU, controllo le code di accettazione, la distribuzione degli IRQ e lo stack di rete. Piccole correzioni ai limiti FD e agli arretrati spesso fanno una grande differenza. <strong>Effetti<\/strong>.<\/p>\n<p>Pianifico in modo realistico l'headroom. Una riserva del 20-30% in thread e FD fornisce sicurezza per i picchi. Se esagero, perdo le cache e gli sprechi aumentano. Se non lo faccio, le richieste finiscono in coda o scadono. La giusta intersezione tra <strong>Capacit\u00e0<\/strong> e l'efficienza mantengono basse le latenze e proteggono la <strong>Stabilit\u00e0<\/strong>.<\/p>\n\n<h2>Coordinare i timeout di client, bilanciatore di carico e firewall<\/h2>\n<p>Ho fissato dei limiti di tempo lungo tutto il percorso, in modo che non ci siano vicoli ciechi. <strong>Connessioni<\/strong> vengono creati. Idealmente, i client chiudono con un minimo di anticipo rispetto al server. Il bilanciatore di carico non deve interrompere le connessioni pi\u00f9 brevi, altrimenti si verificheranno ripristini inaspettati. Includo i valori di inattivit\u00e0 del NAT e del firewall in modo che le connessioni non vadano perse nel percorso di rete. <strong>scomparire<\/strong>. Questa messa a punto evita le ritrasmissioni e attenua le curve di carico.<\/p>\n<p>Uso diagrammi chiari per rendere comprensibile la catena: client \u2192 LB \u2192 server web \u2192 app. Documento i timeout di inattivit\u00e0, i timeout di lettura\/scrittura e le strategie di riprova per ogni collegamento. Se modifico un valore, controllo i vicini. In questo modo mantengo il percorso coerente e ottengo risultati di misura riproducibili. Questa disciplina fa risparmiare tempo nella <strong>Risoluzione dei problemi<\/strong> e aumenta il <strong>affidabilit\u00e0<\/strong>.<\/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\/03\/optimal_configuration_server_9837.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sicurezza: protezione contro i lori lenti e i maltrattamenti<\/h2>\n<p>Timeout aperti troppo generosi <strong>Superfici di attacco<\/strong>. Per questo motivo ho fissato dei limiti che consentono un riutilizzo legittimo, ma rendono pi\u00f9 difficile tenerli aperti in modo malevolo. In nginx, sono utili i limiti di header e read_timeout, request_headers_size e un limite massimo rigido per keepalive_requests. In Apache, uso mod_reqtimeout e limito le connessioni parallele per IP. Limiti di velocit\u00e0 e <strong>limit_conn<\/strong> in nginx proteggono anche dalle inondazioni di molti socket inattivi. Per gli endpoint di lunga durata, separo i pool dedicati, in modo che gli attacchi ai flussi non blocchino i normali worker API.<\/p>\n\n<h2>Casi speciali: Long Polling, SSE e WebSockets<\/h2>\n<p>I flussi lunghi si scontrano con quelli corti <strong>Timeout<\/strong> e necessitano di regole proprie. Tecnicamente separo questi endpoint dalle classiche rotte API e delle risorse. Per SSE e WebSocket, imposto timeout pi\u00f9 elevati, pool di lavoratori dedicati e limiti rigidi per IP. Mantengo viva la connessione con heartbeat o ping\/pong e riconosco rapidamente le disconnessioni. In questo modo, gli stream non bloccano i thread per i regolari <strong>Richieste brevi<\/strong>.<\/p>\n<p>Limito le connessioni simultanee e misuro attivamente. Limiti troppo alti consumano FD e RAM. Limiti troppo stretti tagliano fuori gli utenti legittimi. Trovo il punto di forza con metriche pulite per le connessioni aperte, inattive, attive e interrotte. Questa separazione mi permette di risparmiare sulle connessioni globali. <strong>Aumenta<\/strong> i timeout e protegge il <strong>Capacit\u00e0<\/strong>.<\/p>\n\n<h2>HTTP\/2, multiplexing e keep-alive<\/h2>\n<p>HTTP\/2 multiplexa diversi flussi attraverso un <strong>Connessione<\/strong>, ma rimane dipendente dai timeout. Mantengo una finestra di inattivit\u00e0 moderata, perch\u00e9 le sessioni possono anche parcheggiarsi sotto HTTP\/2. Le keepalive_request elevate sono meno importanti, ma il riciclo rimane utile. Il blocco della linea di testa si sposta a livello di frame, quindi continuo a misurare la latenza per <strong>Flusso<\/strong>. Se si desidera un confronto pi\u00f9 approfondito, \u00e8 possibile trovare informazioni di base su <a href=\"https:\/\/webhosting.de\/it\/http2-multiplexing-vs-http11-prestazioni-background-ottimizzazione\/\">Multiplexing HTTP\/2<\/a>.<\/p>\n<p>Nell'ambito di HTTP\/2, presto particolare attenzione al numero di flussi attivi per connessione. Troppi flussi paralleli possono sovraccaricare i thread dell'applicazione. In tal caso, rallento i limiti o aumento i lavoratori del server. Lo stesso vale in questo caso: misurare, regolare, misurare di nuovo. In questo modo si mantiene il <strong>Tempi di risposta<\/strong> scarso e conservato <strong>Risorse<\/strong>.<\/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\/03\/dev_desk_HTTP_timeout_4783.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>TLS, ripresa della sessione e HTTP\/3\/QUIC<\/h2>\n<p>Le strette di mano TLS sono costose. Io uso <strong>Ripresa della sessione<\/strong> (ticket\/ID) e la pinzatura OCSP, in modo che le riconnessioni siano pi\u00f9 rapide in caso di interruzione della connessione. Nell'ambito di HTTP\/3, QUIC si occupa del livello di trasporto: in questo caso l'elemento <strong>Timeout inattivit\u00e0 QUIC<\/strong> simile a Keep-Alive, ma su base UDP. Anche in questo caso, mantengo le finestre moderate e misuro le ritrasmissioni, poich\u00e9 le perdite di pacchetti hanno un effetto diverso rispetto al TCP. Per gli ambienti misti (H1\/H2\/H3), seleziono valori di riferimento standardizzati ed eseguo regolazioni fini per ciascun protocollo.<\/p>\n\n<h2>Monitoraggio, metriche e test di carico<\/h2>\n<p>Mi fido di pi\u00f9 dei dati di misura che delle sensazioni di pancia e parto da un'idea chiara. <strong>KPI<\/strong>. Sono importanti: socket aperti, utilizzo di FD, nuove connessioni\/s, latenze (P50\/P90\/P99), tassi di errore e ritrasmissioni. Eseguo profili di carico realistici: Riscaldamento, plateau, discesa. Quindi confronto le curve prima e dopo le modifiche al timeout. Uno sguardo a <a href=\"https:\/\/webhosting.de\/it\/server-web-accodamento-latenza-gestione-delle-richieste-coda-del-server\/\">Accodamento server<\/a> aiuta a interpretare chiaramente i tempi di attesa.<\/p>\n<p>Documento ogni regolazione con una marca temporale e i valori misurati. Questo mi permette di conservare la storia e di riconoscere le correlazioni. Prendo sul serio gli effetti negativi e li elimino rapidamente. Piccoli passi comprensibili fanno risparmiare molto tempo. Ci\u00f2 che conta, alla fine, \u00e8 una stabilit\u00e0 <strong>Latenza<\/strong> e basso <strong>Tasso di errore<\/strong> sotto carico.<\/p>\n\n<h2>Metodi e strumenti di misurazione nella pratica<\/h2>\n<ul>\n  <li><strong>Test rapidi:<\/strong> Utilizzo strumenti come wrk, ab o vegeta per controllare le quote di riutilizzo (-H connection: keep-alive vs. close), le connessioni\/s e i percentili di latenza.<\/li>\n  <li><strong>Vista del sistema:<\/strong> ss\/netstat mostra gli stati (ESTABLISHED, TIME_WAIT), lsof -p il consumo di FD, dmesg\/syslog le indicazioni delle cadute.<\/li>\n  <li><strong>Metriche del server web:<\/strong> nginx stub_status\/VTS e Apache mod_status forniscono richieste attive\/idle\/attese. Da questo posso riconoscere i picchi di inattivit\u00e0 o i colli di bottiglia dei lavoratori.<\/li>\n  <li><strong>Tracce:<\/strong> Utilizzo il tracciamento distribuito per monitorare se i tempi di attesa si verificano al confine della rete o nell'applicazione.<\/li>\n<\/ul>\n\n<h2>Configurazione passo dopo passo<\/h2>\n<p>Per prima cosa, determino il modello di utilizzo reale: quante richieste per sessione, quali <strong>Intervalli<\/strong> tra un clic e l'altro, quanto sono grandi le risposte. Poi imposto un profilo iniziale: timeout 10 s, keepalive_requests 200, numero di lavoratori moderato. Eseguo quindi dei test di carico con dati rappresentativi. Valuto il numero di nuove connessioni al secondo e l'utilizzo del FD. Regolo quindi il profilo <strong>Valori<\/strong> con incrementi di 2-3 secondi.<\/p>\n<p>Ripeto il ciclo finch\u00e9 le latenze rimangono stabili sotto carico e i picchi di FD non raggiungono il limite. In caso di traffico intenso, aumento il timeout solo se vedo chiaramente un minor numero di nuove connessioni e i lavoratori rimangono ancora liberi. In caso di basso utilizzo, riduco il timeout per evitare l'inattivit\u00e0. In casi particolari come SSE, imposto blocchi di server dedicati con limiti pi\u00f9 elevati. Questo percorso porta a un sistema resiliente <strong>Impostazione<\/strong> senza cartoncino.<\/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\/03\/servereinstellung-performance-1987.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kubernetes, container e autoscaling<\/h2>\n<p>Negli ambienti container uso <strong>conntrack<\/strong>-limiti, limiti FD dei pod e arretrati dei nodi. Assicuro timeout di inattivit\u00e0 coerenti tra Ingress, service mesh\/proxy e app. Per l'autoscaling, faccio attenzione a <strong>Tempi di scarico<\/strong>Quando i pod vengono terminati, devono rifiutare le nuove connessioni tramite \u201eConnection: close\u201c e servire quelle esistenti in modo pulito. Valori di keep alive troppo lunghi allungano inutilmente i tempi di scaricamento, mentre quelli troppo corti generano tempeste di handshake durante lo scaling out.<\/p>\n\n<h2>Arresto di grazia e implementazioni rolling<\/h2>\n<p>Ho anche intenzione di spegnermi. Prima di un rollout, riduco gradualmente il Keep-Alive o invio messaggi mirati. <strong>Connessione: chiudere<\/strong> sulle risposte, in modo che i client non aprano nuove connessioni inattive. In nginx, un elemento <strong>worker_shutdown_timeout<\/strong> per le richieste in corso. In Apache, uso meccanismi di grazia e tengo d'occhio MaxConnectionsPerChild\/Worker, in modo che il riciclo avvenga automaticamente nel tempo. In questo modo le distribuzioni sono fluide, senza limitare i socket aperti.<\/p>\n\n<h2>Messa a punto del sistema operativo: porte, timeout, parametri del kernel<\/h2>\n<ul>\n  <li><strong>porti effimeri:<\/strong> Selezionate un intervallo ampio per ip_local_port_range, in modo che le connessioni di breve durata non si esauriscano.<\/li>\n  <li><strong>TEMPO_INDIETRO:<\/strong> Osservo i picchi di TW. Gli stack moderni gestiscono bene questo aspetto; evito i tweak pi\u00f9 difficili (tw_recycle).<\/li>\n  <li><strong>tcp_keepalive_time:<\/strong> Non lo confondo con HTTP Keep-Alive. Si tratta di un meccanismo del kernel per riconoscere i peer morti, utile dietro NAT, ma non per sostituire la finestra di inattivit\u00e0 HTTP.<\/li>\n  <li><strong>Arretrati e buffer:<\/strong> dimensionare somaxconn, tcp_max_syn_backlog e rmem\/wmem in modo sensato, per non subire strozzature sotto carico.<\/li>\n<\/ul>\n\n<h2>Lista di controllo per la risoluzione dei problemi<\/h2>\n<ul>\n  <li><strong>Molte nuove connessioni nonostante il keep-alive:<\/strong> Timeout troppo breve o interruzione anticipata dei client\/LB.<\/li>\n  <li><strong>Alti valori di minimo e FD pieni:<\/strong> Timeout troppo lungo o pool di lavoratori troppo grandi per il modello di traffico.<\/li>\n  <li><strong>Errore RST\/Timeout per sessioni pi\u00f9 lunghe:<\/strong> NAT\/firewall inattivo troppo corto nel percorso, asimmetria tra i collegamenti.<\/li>\n  <li><strong>Latenze della coda lunga (P99):<\/strong> Controllare i timeout di invio\/lettura, i client lenti o i backlog troppo pieni.<\/li>\n  <li><strong>I backend sono sovraccarichi nonostante il basso carico dei bordi:<\/strong> La gabbia a monte manca o \u00e8 troppo piccola.<\/li>\n<\/ul>\n\n<h2>Profili di pratica e valori di partenza<\/h2>\n<ul>\n  <li><strong>API-first (chiamate brevi):<\/strong> Keep-Alive 5-10 s, keepalive_requests 200-300, timeout di lettura\/intestazione stretto.<\/li>\n  <li><strong>Commercio elettronico (misto):<\/strong> 8-12 s, 200-400, un po' pi\u00f9 generoso per le immagini dei prodotti e per le visite in cache.<\/li>\n  <li><strong>Assets\/CDN-like (molti file di piccole dimensioni):<\/strong> 10-15 s, 300-500, forti pozze a monte e alti limiti FD.<\/li>\n  <li><strong>Intranet\/carico ridotto:<\/strong> 5-8 s, 100-200, in modo che il minimo non domini.<\/li>\n<\/ul>\n\n<h2>Riassumendo brevemente<\/h2>\n<p>Ho impostato il timeout HTTP keep-alive in modo che le connessioni vengano riutilizzate senza bloccare i thread. In pratica, 5-15 secondi e 100-500 richieste per connessione danno ottimi risultati. Coordino i timeout di client, bilanciatore di carico e firewall, separo le connessioni a lunga durata come i WebSocket e regolo i limiti del sistema operativo. Con un monitoraggio pulito, test di carico realistici e piccoli passi, ottengo risultati bassi. <strong>Latenze<\/strong> e alta <strong>Produttivit\u00e0<\/strong>. Chi mantiene questa disciplina ottiene prestazioni misurabili dall'hardware esistente.<\/p>","protected":false},"excerpt":{"rendered":"<p>Impostazioni ottimizzate del timeout HTTP keep-alive per migliorare le prestazioni del server. Guida pratica per la messa a punto del server web e la gestione delle connessioni.<\/p>","protected":false},"author":1,"featured_media":18049,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-18056","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":"845","_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":"HTTP Keep-Alive Timeout","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":"18049","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/18056","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=18056"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/18056\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/18049"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=18056"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=18056"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=18056"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}