{"id":20714,"date":"2026-08-16T18:19:23","date_gmt":"2026-08-16T16:19:23","guid":{"rendered":"https:\/\/webhosting.de\/nginx-worker-processes-optimal-konfigurieren-performanceboost\/"},"modified":"2026-08-16T18:19:23","modified_gmt":"2026-08-16T16:19:23","slug":"configurazione-ottimale-dei-processi-worker-di-nginx-per-migliorare-le-prestazioni","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/nginx-worker-processes-optimal-konfigurieren-performanceboost\/","title":{"rendered":"Configurare in modo ottimale i processi di lavoro di NGINX per ottenere le massime prestazioni"},"content":{"rendered":"<p>Configurazione <strong>NGINX Worker<\/strong> in modo che worker_processes, worker_connections e worker_rlimit_nofile corrispondano esattamente e Epoll funzioni nel ciclo di eventi. In questo modo utilizzo <strong>Core della CPU<\/strong> Garantisci l'efficienza, rendi scalabili le connessioni simultanee in modo pianificabile e mantieni basse le latenze nei picchi di carico.<\/p>\n\n<h2>Punti centrali<\/h2>\n<p>I seguenti aspetti fondamentali ti forniranno indicazioni immediate per una configurazione robusta dei worker NGINX.<\/p>\n<ul>\n  <li><strong>processi_lavoratori<\/strong> associarlo al numero di core logici, idealmente con \u201eauto\u201c.<\/li>\n  <li><strong>connessioni_lavoratore<\/strong> impostare in modo tale che i picchi reali siano coperti senza problemi.<\/li>\n  <li><strong>rlimit_nofile<\/strong> e aumentare i limiti del sistema operativo in base al volume di traffico.<\/li>\n  <li><strong>epoll<\/strong> e attivare multi_accept per sfruttare in modo efficiente il ciclo degli eventi.<\/li>\n  <li><strong>Prove di carico<\/strong> procedere e apportare piccole modifiche graduali.<\/li>\n<\/ul>\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-optimierung-serverraum-5961.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Architettura NGINX: comprendere i master e i worker<\/h2>\n<p>Distinguo i compiti da <strong>Maestro<\/strong> e i worker: il master carica le configurazioni, apre i socket e avvia i processi, mentre i worker elaborano le richieste nell\u2019event loop. Ogni worker opera in modo autonomo, reagisce agli eventi ed \u00e8 in grado di gestire migliaia di connessioni senza causare blocchi. Questo modello d\u00e0 il meglio di s\u00e9 quando assegno i core della CPU in modo adeguato e gestisco in modo ottimale il ciclo di eventi tramite epoll. Tengo presente che ogni hop aggiuntivo del proxy consuma risorse di connessione, il che si riflette nei limiti. Chi comprende i ruoli, decide consapevolmente in merito a <strong>Risorse<\/strong> e previene tempestivamente le strozzature.<\/p>\n\n<h2>Abbinare correttamente le tre direttive chiave<\/h2>\n<p>Considero <strong>processi_lavoratori<\/strong>, worker_connections e worker_rlimit_nofile non vanno mai considerati isolatamente, ma come un\u2019unica entit\u00e0. Il numero totale di connessioni possibili \u00e8 dato dal numero di worker moltiplicato per le connessioni per worker; da questo calcolo ricavo i limiti per i descrittori di file. Se questi parametri non sono ben coordinati, mi ritrovo a dover affrontare errori del tipo \u201etoo many open files\u201c o a subire timeout severi. Per carichi elevati ho bisogno di una catena ben coordinata: processi sufficienti, connessioni generose, un valore di rlimit_nofile adeguatamente aumentato e parametri del sistema operativo appropriati. In questo modo evito che un valore troppo basso <strong>Limite<\/strong> ne ha compromesso l'intera capacit\u00e0.<\/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_worker_meeting_3021.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>worker_processes: scegliere il numero in modo mirato<\/h2>\n<p>Ho impostato <strong>processi_lavoratori<\/strong> Di norma su \u201eauto\u201c, in modo che NGINX riconosca il numero di core logici della CPU e possa utilizzare ogni singolo core. Un worker per ogni core evita inutili cambi di contesto e distribuisce il carico in modo ottimale, mantenendo prevedibili i tempi di risposta. Su macchine con un numero molto elevato di core, provo intenzionalmente anche un numero inferiore di worker per confrontare gli hit della cache e l\u2019utilizzo dei core. Se le metriche indicano che i core sono sovraccarichi o che aumentano i TLB miss, adeguo gradualmente il numero di worker. Prima misuro, poi modifico: \u00e8 cos\u00ec che mi assicuro risultati affidabili <strong>Risultati<\/strong>.<\/p>\n\n<h2>worker_connections: aumentare le connessioni in modo pianificato<\/h2>\n<p>Scelgo il <strong>connessioni_lavoratore<\/strong> a seconda del traffico di destinazione e della combinazione di protocolli, spesso a partire da 2048 o 4096. Per le API molto trafficate prendo in considerazione 8192, purch\u00e9 i limiti del sistema operativo e la RAM lo consentano. Verifico ogni aumento con test di carico, poich\u00e9 le connessioni aperte occupano memoria e influenzano il comportamento upstream. Se prevalgono gli handshake SSL o gli upload di grandi dimensioni, mi baso maggiormente sui profili della CPU e dell\u2019I\/O, non solo sul numero di connessioni in s\u00e9. In questo modo mi assicuro che il numero definito per ogni worker <strong>Capacit\u00e0<\/strong> rimanga effettivamente utilizzabile.<\/p>\n\n<h2>Sincronizzare worker_rlimit_nofile e i limiti del sistema operativo<\/h2>\n<p>Mi assicuro che <strong>rlimit_nofile<\/strong> copra almeno la capacit\u00e0 totale teorica e spesso sia configurato con una riserva. Per gli scenari con proxy inverso, calcolo un secondo descrittore per l\u2019upstream per ogni connessione client. Di conseguenza, imposto rlimit_nofile a un valore pari al doppio delle connessioni simultanee previste. Aumento i limiti del kernel e dell\u2019utente (ulimit -n, fs.file-max) in modo tale che NGINX possa effettivamente sfruttarne i valori. Se nel log degli errori compaiono messaggi relativi a file aperti, aumento rapidamente i valori e osservo il <strong>Latenza<\/strong> sotto carico, di nuovo.<\/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-5123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Blocco \"Eventi\": utilizzare efficacemente epoll e multi_accept<\/h2>\n<p>Nel blocco \"Eventi\" attivo <strong>epoll<\/strong> e imposto multi_accept su \u201eon\u201c, in modo che i worker accettino le connessioni in attesa in un unico ciclo. Epoll riduce l\u2019overhead in presenza di molti socket simultanei e si integra perfettamente con il design non bloccante di NGINX. Queste opzioni danno i loro frutti durante i picchi di traffico, poich\u00e9 accelerano la fase di accettazione e consentono di passare pi\u00f9 rapidamente all\u2019elaborazione vera e propria. Per Linux questa \u00e8 la mia configurazione standard, che modifico solo in rari casi particolari. Chi desidera approfondire l\u2019argomento pu\u00f2 confrontare il modello dell\u2019event loop con <a href=\"https:\/\/webhosting.de\/it\/threadpool-webserver-apache-nginx-litespeed-ottimizzazione-configurazione\/\">Thread pool vs. ciclo di eventi<\/a> e ne deduce <strong>conclusioni<\/strong> per il proprio ambiente.<\/p>\n\n<h2>Affinit\u00e0 della CPU: associare i worker ai core<\/h2>\n<p>Ho impostato <strong>affinit\u00e0_CPU_del_processore<\/strong> in modo mirato quando i carichi di lavoro sono costanti e vincolati alla CPU. Distribuisco lo schema di assegnazione tramite maschere di bit per evitare i cambi di contesto e favorire la localit\u00e0 della cache. Con quattro core, assegno le maschere in modo che ogni worker abbia un proprio core. Successivamente, analizzo i tassi di cache miss, le latenze mediane e il 99\u00b0 percentile per valutare chiaramente l\u2019effetto. Trovi spiegazioni pi\u00f9 dettagliate sull\u2019affinit\u00e0 e sul NUMA in forma sintetica su <a href=\"https:\/\/webhosting.de\/it\/processo-di-server-affinita-numa-consapevolezza-hosting-ressourcentuning\/\">Affinit\u00e0 della CPU: aspetti pratici<\/a>, il che \u00e8 utile per la messa a punto di <strong>Lavoratore<\/strong>-Aiuta con i layout.<\/p>\n\n<h2>Pianificazione della capacit\u00e0: margine di sicurezza e test di carico<\/h2>\n<p>Quando si tratta di collegamenti, prevedo un <strong>Buffer<\/strong> un valore nettamente superiore ai picchi osservati, in modo che i picchi momentanei non superino direttamente i limiti. Se raddoppio il carico di picco come punto di partenza, in molti scenari dispongo di un solido margine di sicurezza. In caso di traffico fortemente fluttuante, allargo ulteriormente il margine di sicurezza fino a quando i percentili al 99\u00b0 non risultano stabili. Successivamente, verifico i colli di bottiglia con strumenti come wrk o k6, osservo i tassi di errore e controllo le connessioni aperte nella sezione \u201cStato\u201d. Solo quando le metriche sono coerenti, aumento o riduco in modo mirato i singoli <strong>Valori<\/strong>.<\/p>\n\n<h2>Configurazione ed esempi di calcolo<\/h2>\n<p>Calcolo la capacit\u00e0 di connessione moltiplicando il numero di worker per le connessioni per worker e, sulla base di questo, imposto limiti pi\u00f9 elevati. Con quattro core della CPU, l\u2019opzione \u201cauto\u201d e 4096 connessioni per worker, ottengo un risultato teorico di 16384 connessioni simultanee. Negli scenari proxy, tendo a impostare rlimit_nofile a 32768 o oltre, in modo da includere i socket upstream. Per macchine di piccole dimensioni con due core, spesso sono sufficienti 2048 connessioni per worker, a condizione che la percentuale di upload e TLS rimanga moderata. La tabella seguente aiuta a classificare i <strong>valori iniziali<\/strong>:<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Core della CPU<\/th>\n      <th>processi_lavoratori<\/th>\n      <th>worker_connections (Inizio)<\/th>\n      <th>rlimit_nofile min. (valore indicativo)<\/th>\n      <th>Suggerimento<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>2<\/td>\n      <td>auto (\u22482)<\/td>\n      <td>2048<\/td>\n      <td>\u2265 4096<\/td>\n      <td><strong>Riserva<\/strong> Pianificare per TLS\/proxy<\/td>\n    <\/tr>\n    <tr>\n      <td>4<\/td>\n      <td>auto (\u22484)<\/td>\n      <td>4096<\/td>\n      <td>\u2265 16384<\/td>\n      <td>Con il proxy, spesso il fattore \u00e8 2 per gli FD<\/td>\n    <\/tr>\n    <tr>\n      <td>8<\/td>\n      <td>auto (\u22488)<\/td>\n      <td>4096-8192<\/td>\n      <td>\u2265 32768<\/td>\n      <td><strong>Prova di carico<\/strong> decide in merito all'aumento<\/td>\n    <\/tr>\n    <tr>\n      <td>16+<\/td>\n      <td>auto, eventualmente meno<\/td>\n      <td>8192+<\/td>\n      <td>\u2265 65535<\/td>\n      <td>Testare con sensibilit\u00e0 e discrezione<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\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_opt_4732.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NGINX Worker e Upstream: ponderare correttamente gli scenari<\/h2>\n<p>Distinguo tra distribuzione statica, funzionamento con proxy inverso e carico del gateway API, poich\u00e9 essi costituiscono la <strong>Lavoratore<\/strong>-Configurazione diversa. I contenuti statici impiegano meno risorse, mentre TLS, la compressione e le connessioni upstream gravano maggiormente sulla CPU e sugli FD. Pi\u00f9 grandi sono le chiavi SSL e pi\u00f9 numerosi sono gli handshake, maggiore \u00e8 il vantaggio offerto dall\u2019impostazione \u201eun worker per core\u201c. I caricamenti di grandi dimensioni spostano il profilo verso l\u2019I\/O, il che mi porta a prestare maggiore attenzione a rlimit_nofile e ai buffer di rete. In caso di tempi di attesa percepibili per l\u2019accettazione o le risposte del backend, mi \u00e8 utile avere una panoramica per <a href=\"https:\/\/webhosting.de\/it\/server-web-accodamento-latenza-gestione-delle-richieste-coda-del-server\/\">Code e latenza<\/a>, per evitare i punti di strozzatura <strong>mirato<\/strong> risolvere.<\/p>\n\n<h2>Flusso di lavoro pratico: passo dopo passo verso un server pi\u00f9 veloce<\/h2>\n<p>Inizio con un'analisi della situazione attuale di tutti gli elementi rilevanti <strong>Valori<\/strong> Nel file nginx.conf, controllo i core della CPU, i valori di ulimit e i parametri del kernel. Successivamente imposto worker_processes su auto, imposto worker_connections, ad esempio, su 4096 e aumento generosamente il valore di rlimit_nofile. Nel blocco Events attivo epoll e multi_accept e, dopo un reload, controllo i log. Seguono test di carico in condizioni riproducibili, durante i quali osservo i tempi di risposta, i tassi di errore e le connessioni aperte. Nella fase di messa a punto, modifico sempre una sola variabile alla volta, documento ogni passaggio e ne verifico gli effetti nei <strong>Metriche<\/strong>.<\/p>\n\n<h2>Ambiente di hosting: risorse, kernel, rete<\/h2>\n<p>Mi assicuro che ci sia una quantit\u00e0 sufficiente di <strong>CPU<\/strong>-Core, RAM sufficiente, SSD veloci o NVMe e un kernel Linux aggiornato. Solo cos\u00ec epoll, i moderni stack TCP e le funzionalit\u00e0 di offload efficaci funzionano in modo affidabile. Adatto i parametri di rete come somaxconn e tcp_max_syn_backlog al numero desiderato di connessioni, per mantenere brevi le code di accettazione. Un provider con prestazioni I\/O affidabili e una configurazione di sistema liberamente accessibile ripaga chiaramente in questo senso. Dai confronti emerge che i servizi con <strong>Risorse<\/strong> Aumentare notevolmente le possibilit\u00e0 offerte da NGINX.<\/p>\n\n<h2>Strategia Keepalive: connessioni client e upstream<\/h2>\n<p>Utilizzo Keepalive in modo mirato come strumento per ottimizzare la capacit\u00e0 e la latenza. Sul lato client impiego <strong>keepalive_timeout<\/strong> non troppo alto, in modo che i socket inattivi non vengano inutilmente <em>connessioni_lavoratore<\/em> bloccare. Valori compresi tra 10 e 30 s mi offrono spesso un buon compromesso tra riutilizzo e impiego di risorse. Con <strong>keepalive_requests<\/strong> Limito il numero di richieste per connessione, per interrompere le sessioni di lunga durata ed evitare il sovraccarico della memoria. Sul lato upstream (proxy inverso) mantengo connessioni persistenti con <strong>keepalive<\/strong> nel blocco upstream, in modo da evitare gli handshake e la configurazione TCP. A tal fine, dimensiono il numero per ogni backend in modo prudente in base alla capacit\u00e0 del backend (<em>max_conns<\/em>), altrimenti mi ritrovo con code di attesa nell'upstream. Importante: ogni socket keepalive conta come connessione aperta e richiede FD; ne tengo conto in <em>rlimit_nofile<\/em> e la mia pianificazione dell'headroom.<\/p>\n\n<h2>Ottimizzazione delle liste: reuseport, backlog e strategia di accettazione<\/h2>\n<p>Distribuisco il carico in modo uniforme, in modo da <strong>SO_REUSEPORT<\/strong> attiva (listen \u2026 reuseport). Ogni worker dispone cos\u00ec di una propria coda di accettazione, il che riduce il fenomeno dei \u201ethundering herds\u201c ed evita la formazione di punti di congestione. In combinazione con <strong>multi_accept<\/strong> accelero notevolmente la fase di accettazione. L'elenco-<strong>arretrato<\/strong> (listen \u2026 backlog=) e le corrispondenti impostazioni del kernel (somaxconn, tcp_max_syn_backlog) le imposto con valori generosi, in modo che i picchi non vadano persi all\u2019ingresso del socket. L\u2019opzione <strong>differito<\/strong> rimanda l'Accept fino a quando non sono disponibili i dati \u2013 in caso di numerose richieste di breve durata questo pu\u00f2 essere d'aiuto, altrimenti faccio un confronto nei test. Se io <strong>accept_mutex<\/strong> Valuto di cosa ho bisogno nel benchmark: con reuseport, nella maggior parte dei casi \u00e8 superfluo; senza reuseport pu\u00f2 migliorare l\u2019equit\u00e0, ma richiede un maggiore coordinamento. In questo caso prendo decisioni basate sui dati, mai d\u2019istinto.<\/p>\n\n<h2>Configurare in modo stabile i timeout e le code<\/h2>\n<p>Ho impostato <strong>Timeout<\/strong> in modo che i client lenti non intasino i worker: <em>client_header_timeout<\/em> e <em>timeout_corpo_cliente<\/em> Lo mantengo abbastanza conciso da evitare intoppi, ma abbastanza ampio da soddisfare le esigenze degli utenti reali. <em>send_timeout<\/em> impedisce che le risposte verso il client vengano bloccate. Nel contesto del proxy, definisco <em>timeout_connessione_proxy<\/em>, <em>proxy_read_timeout<\/em> e <em>proxy_send_timeout<\/em> in modo rigoroso, affinch\u00e9 i backend in sospeso non blocchino il frontend. Nel caso di backend con parallelismo limitato, utilizzo <strong>coda<\/strong> nel blocco upstream con timeout, per attenuare i picchi e segnalare in modo controllato il codice di errore 503, invece di legare tutti i worker ai socket upstream in attesa. Inoltre, stabilizzo il sistema con <strong>limit_req<\/strong> (Burst\/Delay) e <strong>limit_conn<\/strong> percorsi sensibili, in modo che i singoli client o bot non consumino risorse in modo sproporzionato.<\/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_worker_performance_8392.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Buffering, sendfile e AIO: scegliere con consapevolezza le modalit\u00e0 di I\/O<\/h2>\n<p>Ho impostato <strong>sendfile<\/strong> per i file statici e combinalo con <em>tcp_nopush<\/em>\/<em>tcp_nodelay<\/em> a seconda del carico di lavoro, per raggruppare i pacchetti in modo efficiente o ridurre le latenze interattive. Per i file di grandi dimensioni utilizzo <strong>direzione<\/strong> a partire da una certa soglia, in modo da evitare il cache pollution e impedire che la cache delle pagine venga sovrascritta. In modalit\u00e0 proxy, decido se <strong>proxy_buffering<\/strong> sia d'aiuto (trasferimento rapido al client, lettura upstream disaccoppiata) oppure se, in caso di carichi di streaming, sia preferibile <em>proxy_request_buffering<\/em> ridurre, per avviare i caricamenti in anticipo. Le dimensioni di <em>proxy_buffers<\/em>, <em>proxy_buffer_size<\/em> e <em>buffer di intestazione dei client di grandi dimensioni<\/em> Lo gestisco in modo mirato, affinch\u00e9 l'utilizzo della memoria per ogni connessione non aumenti a dismisura. Per garantire un accesso ai file che non sovraccarichi la CPU, sto valutando <strong>aio<\/strong> (nativo o thread), ma esegui dei test approfonditi, poich\u00e9 le caratteristiche dell'event loop e dell'I\/O si influenzano a vicenda.<\/p>\n\n<h2>HTTP\/2\/HTTP\/3 e TLS: impatto sulla capacit\u00e0 dei worker<\/h2>\n<p>Tengo conto del fatto che <strong>HTTP\/2<\/strong> e <strong>HTTP\/3<\/strong> Modificare la dinamica delle connessioni: molte richieste vengono eseguite come <em>Streaming<\/em> tramite un numero ridotto di connessioni TCP o QUIC. Ci\u00f2 riduce il numero di connessioni, ma aumenta il carico sulla CPU e il consumo di memoria per ogni connessione (multiplexing, compressione delle intestazioni, TLS\/QUIC). Il mio <em>connessioni_lavoratore<\/em> Pertanto non lo interpreto acriticamente come \u201elo stesso numero di richieste\u201c. Osservo <em>flussi concorrenti<\/em> per ogni connessione e adattamento <em>keepalive_timeout<\/em> e, se necessario,. <em>http2_max_concurrent_streams<\/em> . Dal punto di vista del TLS, traggo vantaggio dal Session Resumption (ticket\/cache) e dall\u2019OCSP Stapling; in questo modo evito costosi handshake e mantengo basse le latenze. Il rovescio della medaglia: i keepalive pi\u00f9 lunghi occupano FD e RAM \u2013 quindi pianifico <em>rlimit_nofile<\/em> e quote di memoria con riserve realistiche. Per gli algoritmi di cifratura che richiedono un elevato carico di CPU, vale la pena provare l'affinit\u00e0 e le moderne tecniche di accelerazione crittografica.<\/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-optimaler-setup-9182.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitorabilit\u00e0: stato, registri e metriche<\/h2>\n<p>Garantisco la trasparenza con un approccio snello <strong>Stato<\/strong>-Endpoint (ad es. stub_status) per visualizzare le connessioni attive, gli stati di lettura\/scrittura\/attesa e le richieste accettate. Nei log cerco di ridurre al minimo il rumore: un formato compatto <em>log_format<\/em> con tempo, stato, tempi di upstream e byte \u00e8 sufficiente per la maggior parte delle analisi. In caso di QPS molto elevato, disattivo il log di accesso in modo selettivo (in base alla posizione) oppure memorizzo i log in buffer in modo asincrono, in modo che l'I\/O non rallenti il sistema. Impostare il log degli errori su <em>avvertire<\/em> oppure <em>errore<\/em> e passa temporaneamente a <em>debug<\/em>. Correlando costantemente le latenze (mediana\/95\u00b0\/99\u00b0 percentile), le connessioni aperte, i tassi di errore del backend e il carico della CPU per ciascun worker, ne deduco gli adeguamenti delle tre direttive chiave e rilevo tempestivamente eventuali effetti di saturazione.<\/p>\n\n<h2>Container e ambienti virtuali: superare i limiti in modo pulito<\/h2>\n<p>Sto verificando nei container il <strong>cgroup<\/strong>-Imposta i limiti per CPU, RAM e PID e allineali alle impostazioni di NGINX. <em>ulimit -n<\/em> deve essere sufficientemente alto all'interno del container, altrimenti le mie modifiche a `rlimit_nofile` non avranno effetto. Per le quote CPU (ad es. 2 vCPU) imposto <em>processi_lavoratori<\/em> Di conseguenza, affinch\u00e9 la pianificazione non crei un sovraccarico artificiale. In prossimit\u00e0 della rete, nelle modalit\u00e0 di rete \u201ehost\u201c traggo vantaggio da una minore latenza di overhead, mentre gli overlay comportano hop aggiuntivi. Su host multi-NUMA, presto attenzione all\u2019affinit\u00e0 e ai socket di memoria, in modo che i worker non operino trasversalmente ai nodi. Lo stesso vale per l\u2019affinit\u00e0 IRQ e RPS\/XPS: se i percorsi dalla scheda di rete (NIC) attraverso l\u2019IRQ fino al kernel del worker sono corretti, i picchi di latenza diminuiscono in modo misurabile.<\/p>\n\n<h2>Ciclo di vita delle connessioni: porte effimere, TIME_WAIT e riserve<\/h2>\n<p>Prevedo di avere abbastanza <strong>porte effimere<\/strong> (ip_local_port_range), quando NGINX agisce come client attivo nei confronti degli upstream. In caso di throughput di connessione molto elevato, evito un\u2019eccessiva fluttuazione delle porte utilizzando l\u2019upstream keepalive, il che riduce le code TIME_WAIT. Utilizzo con cautela le opzioni del kernel relative al \u201eriutilizzo\u201c; gli stack moderni ottimizzano gi\u00e0 gran parte dei processi internamente. \u00c8 pi\u00f9 stabile controllare la durata delle connessioni tramite valori ragionevoli di keepalive e timeout e <em>riuso<\/em> per garantire una distribuzione equa. Nel calcolo della capacit\u00e0, oltre ai client, tengo sempre in considerazione anche il lato upstream: spesso sono proprio gli FD a rappresentare il vero fattore limitante, non il frontdoor.<\/p>\n\n<h2>Ricaricamenti e distribuzioni fluidi senza interruzioni<\/h2>\n<p>Utilizzo il modello master\/worker per <strong>ricariche fluide<\/strong>: Il master carica le nuove configurazioni; i vecchi worker si disconnettono, mentre quelli nuovi subentrano senza interruzioni. Con <em>worker_shutdown_timeout<\/em> Lascio che le richieste si completino correttamente senza bloccare le risorse. Abbino le distribuzioni a tempo zero sull'upstream a controlli di integrit\u00e0 e <em>proxy_next_upstream<\/em>-Regole per evitare che singoli backend difettosi facciano aumentare la latenza globale. Quando apporto modifiche alla configurazione, cambio sempre un solo parametro alla volta e ne verifico gli effetti nei log e nelle metriche: in questo modo evito errori dovuti alla confusione e mantengo le prestazioni riproducibili.<\/p>\n\n<h2>Sintesi concisa<\/h2>\n<p>Mi collego <strong>processi_lavoratori<\/strong> Imposta il numero di core (idealmente in modalit\u00e0 automatica), configura worker_connections in base al picco di carico e aumenta generosamente rlimit_nofile insieme ai limiti del sistema operativo. Nel blocco Events utilizzo epoll e multi_accept, verifico il tutto con test di carico riproducibili e poi effettuo le regolazioni necessarie a piccoli passi. Per i carichi di lavoro proxy, prevedo descrittori aggiuntivi e testo l\u2019affinit\u00e0 della CPU quando i carichi di lavoro sono costanti. Uno stack configurato correttamente con un kernel adeguato, I\/O veloce e parametri di rete ottimali fa la differenza. Ecco come ottengo <strong>NGINX<\/strong> affidabile nel campo delle prestazioni richiesto dalle pagine e dalle API pi\u00f9 esigenti.<\/p>","protected":false},"excerpt":{"rendered":"<p>Scopri come configurare correttamente i processi di lavoro di NGINX e come migliorare notevolmente le prestazioni del server web grazie a un\u2019ottimizzazione mirata di NGINX.<\/p>","protected":false},"author":1,"featured_media":20707,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20714","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":"135","_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 Worker","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":"20707","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20714","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=20714"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20714\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/20707"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=20714"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=20714"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=20714"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}