{"id":20722,"date":"2026-08-17T08:35:37","date_gmt":"2026-08-17T06:35:37","guid":{"rendered":"https:\/\/webhosting.de\/nginx-worker-connections-skalierung-tausender-requests-trafficboost\/"},"modified":"2026-08-17T08:35:37","modified_gmt":"2026-08-17T06:35:37","slug":"nginx-connessioni-dei-worker-scalabilita-di-migliaia-di-richieste-aumento-del-traffico","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/nginx-worker-connections-skalierung-tausender-requests-trafficboost\/","title":{"rendered":"Connessioni dei worker NGINX \u2013 Scalabilit\u00e0 di migliaia di richieste per le massime prestazioni di hosting"},"content":{"rendered":"<p>Scalo i worker di Nginx in modo mirato per gestire migliaia di richieste simultanee con un basso <strong>Latenza<\/strong> da gestire. La chiave sta in una combinazione ben calibrata di worker_processes, worker_connections, descrittori di file e <strong>Eventi<\/strong>.<\/p>\n\n<h2>Punti centrali<\/h2>\n<ul>\n  <li><strong>Capacit\u00e0<\/strong> = worker_processes \u00d7 worker_connections; nel caso di un reverse proxy, spesso determinato dalle connessioni client e upstream <strong>raddoppiato<\/strong>.<\/li>\n  <li><strong>Descrittori di file<\/strong> (worker_rlimit_nofile, ulimit) in base al carico di connessioni previsto <strong>ascensore<\/strong>.<\/li>\n  <li><strong>Eventi<\/strong>-Blocco con epoll, multi_accept e backlog del kernel in condizioni di carico elevato <strong>rifinire<\/strong>.<\/li>\n  <li><strong>Monitoraggio<\/strong> tramite stub_status e test di carico per iterativi <strong>Personalizzazione<\/strong>.<\/li>\n  <li><strong>Scala<\/strong> Combinazione verticale e orizzontale, configurazione <strong>disaccoppiare<\/strong>.<\/li>\n<\/ul>\n\n<h2>Architettura NGINX: Master, Worker ed eventi<\/h2>\n<p>NGINX si basa su un processo master che avvia diversi worker e li gestisce in modo efficiente con <strong>Eventi<\/strong> gestisce. Anzich\u00e9 elaborare thread per ogni richiesta, ogni worker gestisce numerose connessioni in modo non bloccante tramite un modello basato sugli eventi con un basso <strong>Spese generali<\/strong>. Impostiamo la direttiva `worker_processes` su `auto`, in modo che NGINX sfrutti i core della CPU e ogni unit\u00e0 disponga di un proprio worker. In questo modo distribuiamo meglio le connessioni in entrata e manteniamo bassa la latenza durante i picchi di carico <strong>basso<\/strong>. Per approfondire la pianificazione dei processi, rimando a <a href=\"https:\/\/webhosting.de\/it\/configurazione-ottimale-dei-processi-worker-di-nginx-per-migliorare-le-prestazioni\/\">Ottimizzare i processi dei worker<\/a>, poich\u00e9 una corretta parallelizzazione determina la capacit\u00e0 di connessione effettiva. \u00c8 fondamentale che il parametro `worker_connections` sia dimensionato in modo adeguato per ciascun worker, affinch\u00e9 la moltiplicazione per il numero di processi dia come risultato il valore atteso <strong>Carico di picco<\/strong> copre.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx-worker-rechenzentrum-7421.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Formula della capacit\u00e0: worker_processes \u00d7 worker_connections<\/h2>\n<p>Calcolo la capacit\u00e0 approssimativa con worker_processes \u00d7 worker_connections, tenendo conto che le richieste proxy spesso occupano due connessioni per ogni accesso utente, dimezzando cos\u00ec il numero effettivo <strong>pu\u00f2<\/strong>. Molte installazioni standard partono con 512 connessioni per worker, il che spesso risulta insufficiente per i carichi di lavoro in produzione <strong>\u00e8<\/strong>. I valori iniziali consigliati in pratica si aggirano in genere tra 1024 e 4096 e dipendono dal profilo del traffico e dall'hardware. Prevedo un margine di sicurezza, ovvero almeno il doppio del carico di picco misurato, per gestire in modo sicuro i picchi di traffico <strong>ammortizzare<\/strong>. Rimane importante la convalida tramite test e metriche in tempo reale, affinch\u00e9 i numeri non diventino un semplice gioco teorico <strong>diventare<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Scenario<\/strong><\/th>\n      <th><strong>processi_lavoratori<\/strong><\/th>\n      <th><strong>connessioni_lavoratore<\/strong><\/th>\n      <th><strong>Teoricamente max.<\/strong><\/th>\n      <th><strong>Effettivo (proxy)<\/strong><\/th>\n      <th><strong>FD per lavoratore<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Sito di piccole dimensioni<\/td>\n      <td>2<\/td>\n      <td>1024<\/td>\n      <td>2048<\/td>\n      <td>~1024<\/td>\n      <td>\u22651024<\/td>\n    <\/tr>\n    <tr>\n      <td>API a carico medio<\/td>\n      <td>4<\/td>\n      <td>2048<\/td>\n      <td>8192<\/td>\n      <td>~4096<\/td>\n      <td>\u22652048<\/td>\n    <\/tr>\n    <tr>\n      <td>Orari di punta del negozio<\/td>\n      <td>8<\/td>\n      <td>4096<\/td>\n      <td>32768<\/td>\n      <td>~16384<\/td>\n      <td>\u22654096<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>HTTP\/1.1, HTTP\/2 e TLS: impatto sui worker e sulla latenza<\/h2>\n<p>I protocolli determinano il profilo di connessione. Con HTTP\/1.1 osservo spesso molte connessioni TCP simultanee per ogni client, mentre HTTP\/2 le riduce a pochi stream, che per\u00f2 sono sottoposti a un carico maggiore <strong>fasci<\/strong>. Questo consente di risparmiare descrittori di file, ma trasferisce il carico sui buffer e sulla gestione delle priorit\u00e0. Con TLS, faccio attenzione al riutilizzo delle sessioni, in modo che non si debbano eseguire costosi handshake per ogni richiesta <strong>rallentare<\/strong>. Una cache di sessione condivisa e timeout adeguati riducono i picchi di carico della CPU. Inoltre, non imposto un valore troppo basso per keepalive_requests, in modo che le connessioni di lunga durata possano sfruttare i propri vantaggi <strong>giocare fuori<\/strong>. Per HTTP\/2 calcolo una maggiore concorrenza per ogni connessione e mi assicuro che i buffer di invio\/ricezione siano sufficientemente capienti, senza occupare memoria <strong>sprecare<\/strong>. In presenza di traffico misto, pianifico in modo prudente e verifico gli effetti per ciascuna variante di protocollo nel <strong>Test<\/strong>.<\/p>\n\n<h2>Impostare correttamente i descrittori di file e ulimit<\/h2>\n<p>Ogni connessione richiede almeno un descrittore di file; nel caso dei proxy inversi, spesso ne occorrono due, motivo per cui valori bassi di ulimit possono causare gravi <strong>Confini<\/strong> impostare. Aumento il valore di worker_rlimit_nofile in modo tale che worker_processes \u00d7 worker_connections sia realizzabile e che vi siano riserve per log, socket e cache. A livello di sistema, modifico i file limits.conf e fs.file-max affinch\u00e9 il sistema operativo consenta il numero previsto di file aperti e non si verifichino interruzioni premature <strong>freni<\/strong>. Tramite `ulimit -n` e i parametri di Systemd (LimitNOFILE) verifico se la configurazione rimane stabile e se \u00e8 compatibile con NGINX. Chi ignora questa impostazione, nonostante un valore elevato di `worker_connections`, si trover\u00e0 improvvisamente di fronte a connessioni rifiutate e a un aumento di <strong>Latenze<\/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\/08\/nginx_worker_connections_3894.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ottimizzazione del blocco eventi: epoll, multi_accept, backlog<\/h2>\n<p>Su Linux utilizzo epoll, poich\u00e9 questo meccanismo gestisce in modo efficiente un numero elevato di connessioni tramite operazioni asincrone <strong>Eventi<\/strong> gestisce. Con l'opzione `multi_accept` impostata su `on`, un worker accetta pi\u00f9 nuove connessioni per ogni evento, il che attenua i picchi di carico e riduce i ritardi nell'accettazione <strong>si abbassa<\/strong>. Aumento opportunamente i parametri del kernel come net.core.somaxconn e net.ipv4.tcp_max_syn_backlog, in modo che le code di accettazione non vadano in overflow durante i picchi di traffico. Le ottimizzazioni TIME_WAIT, come tcp_tw_reuse, riducono i colli di bottiglia delle porte e mantengono la curva di throughput <strong>alto<\/strong>. Per approfondire gli aspetti relativi alla concorrenza e alle code, vale la pena dare un\u2019occhiata a <a href=\"https:\/\/webhosting.de\/it\/threadpool-webserver-apache-nginx-litespeed-ottimizzazione-configurazione\/\">Ottimizzazione del thread pool<\/a>, anche se NGINX funziona principalmente in base agli eventi e risulta quindi molto efficiente in termini di risorse <strong>scalare<\/strong>.<\/p>\n\n<h2>Distribuzione corretta dei socket di lista: reuseport, backlog e accept_mutex<\/h2>\n<p>In presenza di un numero molto elevato di connessioni simultanee, ridimensiono attivamente il percorso di accettazione. Con <strong>riuso<\/strong> Ogni worker riceve un proprio socket di ascolto; in questo modo si elimina la concorrenza durante l'accettazione e il carico viene distribuito in modo uniforme su tutti i core. Impostiamo esplicitamente il backlog di ascolto per gestire brevi picchi di traffico. In questa configurazione, accept_mutex non \u00e8 pi\u00f9 necessario. Senza reuseport, invece, accept_mutex pu\u00f2 <strong>aiutare<\/strong>, per attenuare gli effetti di massa su Accept. Importante: le dimensioni del backlog in NGINX e nel kernel (somaxconn) dovrebbero <strong>si incastrano tra loro<\/strong>, altrimenti l'effetto svanir\u00e0.<\/p>\n<pre><code>events {\n    use epoll;\n    worker_connections 4096;\n    # accept_mutex on;   # con reuseport solitamente non necessario\n}\n\nserver {\n    listen 443 ssl http2 reuseport backlog=65535;\n    # ...\n}\n<\/code><\/pre>\n<p>Inoltre, se necessario, assegno i worker ai core della CPU (worker_cpu_affinity), in modo che le linee di cache e il carico IRQ rimangano stabili. In ambienti fortemente NUMA, ci\u00f2 riduce l'inutile <strong>Traffico trasversale<\/strong> nella memoria.<\/p>\n\n<h2>Proxy inverso, upstream e Keep-Alive<\/h2>\n<p>In qualit\u00e0 di proxy inverso, NGINX mantiene spesso due connessioni per ogni richiesta: una con il client e una con il backend, il che rende la pianificazione della capacit\u00e0 realistica <strong>doppio<\/strong> \u00e8 importante. Attivo Keep-Alive in modo mirato, affinch\u00e9 le connessioni upstream rimangano riutilizzabili e l'overhead per ogni richiesta <strong>diminuzioni<\/strong>. In questo modo riduco il carico su PHP-FPM, sul server delle applicazioni o sui microservizi e ottengo slot liberi per nuove sessioni utente. L'equilibrio tra timeout, durata di inattivit\u00e0 e riutilizzo determina la pulizia con cui le connessioni vengono riciclate <strong>diventare<\/strong>. Chi desidera approfondire gli aspetti fondamentali dell'argomento, pu\u00f2 consultare <a href=\"https:\/\/webhosting.de\/it\/connessioni-persistenti-http-utilizzo-del-server-web-prestazioni-di-rete\/\">Connessioni persistenti<\/a> consigli pratici sull'utilizzo delle risorse e su come migliorare la rete<strong>Utilizzare<\/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\/08\/nginx-worker-connections-scalability-2941.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Pool upstream, timeout e tentativi di ripetizione<\/h2>\n<p>Per evitare che i worker debbano attendere backend lenti, impiego timeout ridotti e tentativi di ricarica ben dosati. Mantengo i pool di keepalive upstream sufficientemente grandi da mantenere attive le connessioni, ma non cos\u00ec grandi da far s\u00ec che i file descriptor inattivi occupino memoria e slot <strong>legare<\/strong>. Limito i tentativi di riprova a un numero ridotto e cambio solo in caso di evidenti errori di trasmissione: in questo modo evito l'effetto \"thundering herd\" in caso di brevi interruzioni del backend.<\/p>\n<pre><code>upstream app_backend {\n    server 10.0.0.11:8080 max_fails=3 fail_timeout=10s;\n    server 10.0.0.12:8080 max_fails=3 fail_timeout=10s;\n    keepalive 64;  Connessioni upstream riutilizzabili #\n}\n\nserver {\n    location \/ {\n proxy_pass http:\/\/app_backend;\n proxy_connect_timeout   2s;\n        proxy_read_timeout 15s;\n proxy_send_timeout 15s;\n proxy_next_upstream     error timeout http_502 http_503;\n proxy_next_upstream_tries 2;\n    }\n}\n<\/code><\/pre>\n<p>Allo stesso tempo, regolo i parametri Keep-Alive (timeout, richieste per connessione) per liberare rapidamente le risorse occupate dai client che si connettono raramente <strong>da sbloccare<\/strong>.<\/p>\n\n<h2>Pianificare il ridimensionamento in modo oculato: combinare l\u2019approccio verticale e quello orizzontale<\/h2>\n<p>Per gestire volumi di traffico elevati, ricorro sia al ridimensionamento verticale che a quello orizzontale <strong>Considerazioni<\/strong>. Effettuo lo scalamento verticale aumentando il numero di core della CPU, la RAM, utilizzando SSD veloci e ottimizzando la configurazione di rete, in modo che ogni worker funzioni in modo fluido <strong>opere<\/strong>. A livello orizzontale, espando il sistema con nodi NGINX stateless, una configurazione gestita centralmente e una registrazione distribuita, in modo che la capacit\u00e0 complessiva cresca in modo lineare <strong>cresce<\/strong>. Le cache locali e le politiche ben definite tramite Maps o API consentono di implementare rapidamente le modifiche. Questa separazione riduce gli effetti collaterali e aiuta a gestire nuovi modelli di traffico senza dover apportare modifiche a ciascun nodo <strong>servire<\/strong>.<\/p>\n\n<h2>Prospettiva dell'hosting: latenza, tassi di errore ed esperienza utente<\/h2>\n<p>Un numero insufficiente di worker_connections comporta connessioni rifiutate, timeout e prestazioni scadenti <strong>Esperienza dell'utente<\/strong>. Le applicazioni dinamiche come i CMS o gli shop online ne risentono immediatamente, poich\u00e9 la visualizzazione di una pagina genera diverse richieste al backend e gli slot si esauriscono pi\u00f9 rapidamente <strong>breve<\/strong> . Per questo motivo inizio con valori moderati, come 1024 o 2048 per worker, e li aumento gradualmente sulla base di valori misurati effettivamente rilevati. Parallelmente, mantengo efficienti i servizi a monte e mi assicuro che ci siano descrittori di file sufficienti, in modo da evitare che si verifichino <strong>Limiti<\/strong> intervenire. I benchmark dimostrano che le piattaforme accuratamente ottimizzate offrono vantaggi concreti in questo ambito e gestiscono in modo affidabile i picchi di traffico <strong>intercettazione<\/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\/08\/nginx_worker_connections_performance_2394.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Memoria, buffering e percorsi I\/O<\/h2>\n<p>Ogni connessione occupa memoria di lavoro per i metadati e i buffer. Impostiamo i valori di `proxy_buffers`, `client_body_buffer_size` e `large_client_header_buffers` in modo tale che le richieste tipiche possano essere gestite senza consumare eccessivamente RAM in caso di valori anomali. <strong>legare<\/strong>. Per i contenuti statici, sendfile e tcp_nopush accelerano la distribuzione, mentre tcp_nodelay \u00e8 indicato per risposte brevi in cui la latenza \u00e8 un fattore critico <strong>Importante<\/strong> rimane. Se gli asset si trovano su uno storage pi\u00f9 lento, l\u2019uso di aio threads e thread_pool aiuta ad attenuare gli effetti di blocco. Con open_file_cache riduco gli accessi ai file e le chiamate a stat(), ma tengo conto del fabbisogno aggiuntivo di FD. Scrivo i log in modalit\u00e0 buffer (access_log \u2026 buffer=\u2026 flush=\u2026), in modo che i picchi di I\/O non influenzino i tempi di risposta <strong>influenzare<\/strong>.<\/p>\n\n<h2>Equilibrio tra sicurezza e prestazioni TLS<\/h2>\n<p>Gli handshake TLS richiedono un elevato carico di lavoro della CPU. Combino il riutilizzo delle sessioni con parametri di chiave moderati e attivo ottimizzazioni cumulabili come le cache di sessione e i ticket, purch\u00e9 siano operative <strong>in forma<\/strong>. Il giusto equilibrio tra sicurezza e prestazioni mantiene stabili le latenze senza compromettere la qualit\u00e0 della crittografia. In condizioni di carico elevato, osservo separatamente i percentili 95\u00b0 e 99\u00b0, poich\u00e9 altrimenti i picchi TLS rimarrebbero nascosti dietro i valori medi <strong>nascondersi<\/strong>. HTTP\/2 riduce il numero di connessioni, ma richiede attenzione nella gestione del flusso e nella compressione delle intestazioni per tenere sotto controllo i profili di utilizzo della CPU e della memoria <strong>conservare<\/strong>.<\/p>\n\n<h2>Resilienza sotto carico eccessivo: limiti e rilascio graduale<\/h2>\n<p>Per preservare la latenza, \u00e8 necessario un approccio mirato <strong>Modellatura<\/strong> indispensabile nei momenti di picco di carico. Con limit_conn limito le connessioni parallele per chiave (ad es. IP o sessione), mentre limit_req riduce il carico a raffica e protegge i backend dai carichi sincroni <strong>Assalto<\/strong>. Per gli endpoint critici applico regole pi\u00f9 rigorose rispetto alle risorse statiche. Se si verifica un picco di carico improvviso, restituisco codici di errore 429\/503 ben definiti con Retry-After, invece di distribuire tutte le richieste in modo uniforme <strong>morire di fame<\/strong> . Interrompo le connessioni persistenti (lingering_close) per liberare le risorse in modo controllato e per prevenire i modelli di attacco Slowloris <strong>confutare<\/strong>. Questo processo di shedding attivo mantiene la latenza p95\/p99 entro i limiti di sicurezza, anche quando la domanda complessiva supera temporaneamente la capacit\u00e0 nominale <strong>bugie<\/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\/08\/hosting-performance-9047.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Integrazione di container e sistemi: superare i limiti proprio dove si presentano<\/h2>\n<p>Nei container spesso valgono limiti pi\u00f9 restrittivi. Verifico i limiti dei cgroup (CPU, RAM), imposto ulimit -n in modo adeguato all'interno del container e integro LimitNOFILE nella definizione del servizio. I parametri sysctl come somaxconn e tcp_max_syn_backlog devono essere impostati sul <strong>Ospite<\/strong> diventa effettiva; gli spazi dei nomi non sempre isolano queste impostazioni in modo trasparente. Sulle piattaforme orchestrate pianifico la capacit\u00e0 per pod\/nodo, assegno i worker ai core assegnati e mi assicuro che i percorsi di rete siano stabili (ad es. senza hop NAT superflui), in modo che la curva di latenza <strong>tranquillo<\/strong> rimane. Accompagno gli aggiornamenti continui con worker_shutdown_timeout, in modo che le connessioni esistenti vengano chiuse correttamente <strong>esaurirsi<\/strong>.<\/p>\n\n<h2>Monitoraggio e ottimizzazione iterativa<\/h2>\n<p>Senza visibilit\u00e0, gli interventi di tuning rimangono <strong>Il rischio<\/strong>. Attivo stub_status o strumenti alternativi per monitorare costantemente le connessioni attive, i tassi di accettazione e i rifiuti. Nei test di carico simulo modelli di accesso realistici e identifico i colli di bottiglia nelle code di accettazione, nelle latenze a monte o nella CPU-<strong>Saturazione<\/strong>. Successivamente, regolo con cautela i valori di worker_connections, i processi, i limiti dei file e i parametri TCP, verificandone nuovamente l'effetto. Questo ciclo garantisce l'affidabilit\u00e0 della piattaforma ed evita sorprese in momenti inopportuni <strong>I tempi<\/strong>.<\/p>\n\n<h2>Configurazione di esempio e procedura di calcolo<\/h2>\n<p>Supponendo che, nelle ore di punta, mi aspetti 2000 richieste in-flight simultanee e utilizzi un reverse proxy, calcolo approssimativamente 4000 slot di connessione pi\u00f9 <strong>Buffer<\/strong>. Se NGINX gira su quattro core della CPU, di solito imposto `worker_processes auto` e `worker_connections` tra 1000 e 2000 per ogni worker. Impostiamo il limite dei descrittori di file per ogni worker a un valore sufficientemente alto, in modo che le connessioni, i log e i socket interni abbiano spazio a sufficienza <strong>Luogo<\/strong> . Impostiamo il blocco Events su epoll, attiviamo multi_accept e aumentiamo i backlog del kernel in base al nostro traffico di picco. Un frammento minimalista potrebbe presentarsi cos\u00ec, che poi perfezioner\u00f2 con dei benchmark <strong>Voto<\/strong>:<\/p>\n<pre><code>worker_processes  auto;\nworker_rlimit_nofile  65535;\n\nevents {\n    use epoll;\n    worker_connections  2048;\n    multi_accept on;\n}\n\nhttp {\n    keepalive_timeout   65;\n    sendfile on;\n    # ulteriori opzioni proxy\/cache ...\n}\n<\/code><\/pre>\n<p>Inoltre, integro le ottimizzazioni relative alle liste e all'upstream per perfezionare il percorso di accettazione e quello del backend sotto carico:<\/p>\n<pre><code>events {\n    use epoll;\n    worker_connections 4096;\n    # worker_cpu_affinity auto;  # assegnare i core in modo fisso se necessario\n}\n\nhttp {\n    # ottimizzazioni TLS\/sessione a titolo esemplificativo\n    ssl_session_cache    shared:SSL:50m;\n    ssl_session_timeout  1h;\n\n upstream app_backend {\n server 10.0.0.11:8080;\n server 10.0.0.12:8080;\n keepalive 64;\n    }\n\n    server {\n listen 443 ssl http2 reuseport backlog=65535;\n\n location \/ {\n proxy_pass http:\/\/app_backend;\n proxy_connect_timeout     2s;\n            proxy_read_timeout 15s;\n proxy_next_upstream error timeout http_502 http_503;\n proxy_next_upstream_tries 2;\n }\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\/08\/developer_desk_nginx_5823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>In breve: valori di riferimento concreti<\/h2>\n<p>Adatto il valore di `worker_processes` al numero di core della CPU e imposto `worker_connections` solitamente tra 1024 e <strong>4096<\/strong>. Con il reverse proxy, prevedo due connessioni per ogni richiesta e mantengo un margine di almeno il doppio rispetto al picco misurato<strong>Carico<\/strong>. Impostiamo worker_rlimit_nofile e i limiti a livello di sistema a valori sufficientemente alti affinch\u00e9 i valori specificati nel file nginx.conf rimangano effettivamente utilizzabili. Nel blocco Events impostiamo epoll e multi_accept, mentre i backlog del kernel gestiscono brevi picchi di traffico <strong>ammortizzare<\/strong>. Attraverso il monitoraggio e gli adeguamenti graduali, ne ricavo un motore di traffico affidabile, in grado di gestire in modo ordinato il numero crescente di visite <strong>porta<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Scopri come configurare correttamente le connessioni dei worker di NGINX per scalare NGINX in modo sicuro e ottimizzare le prestazioni di hosting in presenza di migliaia di richieste.<\/p>","protected":false},"author":1,"featured_media":20715,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20722","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":"120","_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":"20715","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20722","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=20722"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20722\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/20715"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=20722"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=20722"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=20722"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}