{"id":21151,"date":"2026-08-29T18:19:12","date_gmt":"2026-08-29T16:19:12","guid":{"rendered":"https:\/\/webhosting.de\/nginx-buffering-performance-speicher-proxy\/"},"modified":"2026-08-29T18:19:12","modified_gmt":"2026-08-29T16:19:12","slug":"nginx-buffer-prestazioni-memoria-proxy","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/nginx-buffering-performance-speicher-proxy\/","title":{"rendered":"Buffering del proxy NGINX: ottimizzazione delle prestazioni e della memoria"},"content":{"rendered":"<p><strong>Buffering di NGINX<\/strong> determina la velocit\u00e0 con cui il tuo proxy riceve le risposte dall'upstream, le memorizza nella cache e le invia ai client, ottimizzando l'uso della memoria. Ti mostrer\u00f2 come ridurre la latenza, chiudere tempestivamente le connessioni al backend e il <strong>Memoria<\/strong> e lo tengo sotto controllo.<\/p>\n\n<h2>Punti centrali<\/h2>\n<p>I seguenti aspetti fondamentali mi aiutano a trovare il giusto equilibrio tra prestazioni e consumo di memoria.<\/p>\n<ul>\n  <li><strong>Disaccoppiamento<\/strong> La comunicazione tra client e backend riduce il tempo di connessione e aumenta la velocit\u00e0 di trasmissione.<\/li>\n  <li><strong>Dimensioni dei buffer<\/strong> Selezionare con precisione per risparmiare RAM ed evitare operazioni di I\/O su disco.<\/li>\n  <li><strong>buffer occupati<\/strong> limitare la memoria attiva durante la trasmissione.<\/li>\n  <li><strong>Eccezioni relative allo streaming<\/strong> utilizzarlo in modo ottimale senza buffering.<\/li>\n  <li><strong>Monitoraggio<\/strong> e i test di carico garantiscono la sicurezza di ogni modifica.<\/li>\n<\/ul>\n\n<h2>Come funziona il proxy-buffering in NGINX<\/h2>\n<p>Utilizzo attivamente <strong>Buffering<\/strong>, in modo che NGINX raccolga rapidamente le risposte dall'upstream e le distribuisca poi autonomamente ai client. Questo disaccoppiamento riduce il <strong>Latenza<\/strong> sul backend, poich\u00e9 l\u2019applicazione viene elaborata pi\u00f9 rapidamente e chiude la connessione prima. Mentre i client si caricano a velocit\u00e0 variabile, il livello proxy regola l\u2019invio dalla memoria RAM. Se i dati non entrano completamente nella RAM, NGINX pu\u00f2 ricorrere temporaneamente ai file, riuscendo comunque a inoltrare la risposta in modo affidabile. \u00c8 proprio questo comportamento a stabilizzare i sistemi sottoposti a carico elevato con molte connessioni simultanee <strong>Connessioni<\/strong>.<\/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-proxy-buffering-4082.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Quando il buffering attivo \u00e8 la scelta migliore<\/h2>\n<p>Nel caso di applicazioni web classiche, API con risposte di dimensioni medie o stack WordPress, offre <strong>Buffering<\/strong> ottengo regolarmente i migliori risultati. Libero il backend prima, mentre NGINX si occupa del resto del trasferimento verso reti client spesso eterogenee. In questo modo aumenta l'effettivo <strong>Produttivit\u00e0<\/strong>, soprattutto quando sono in corso molte richieste contemporaneamente. Chi raggruppa pi\u00f9 servizi dietro un proxy inverso beneficia inoltre di una distribuzione controllata del carico. Per le questioni relative all\u2019architettura dei proxy, mi \u00e8 d\u2019aiuto una chiara <a href=\"https:\/\/webhosting.de\/it\/configurazioni-di-reverse-proxy-architettura-di-webhosting-proxyhosting\/\">Architettura del reverse proxy<\/a>, che distingue chiaramente i ruoli e i limiti.<\/p>\n\n<h2>Memoria vs. I\/O: il budget giusto<\/h2>\n<p>Cerco di trovare un equilibrio tra la RAM e gli accessi al disco rigido, perch\u00e9 buffer troppo piccoli causano inutili <strong>I\/O disco<\/strong> e buffer troppo grandi ingombrano la memoria per ogni connessione. Sono determinanti le dimensioni tipiche delle risposte, le richieste parallele e la reale <strong>Velocit\u00e0 del client<\/strong>. Idealmente, le risposte di piccole dimensioni rimangono interamente nella RAM, consentendo a NGINX di trasmetterle senza tempi di attesa ai destinatari pi\u00f9 lenti. I corpi molto grandi possono essere salvati su disco, ma in tal caso mi assicuro di utilizzare unit\u00e0 veloci e di impostare limiti per evitare un carico eccessivo di I\/O. Questo equilibrio mantiene la <strong>Tempi di risposta<\/strong> bassa e protegge il sistema dalla pressione di accumulo.<\/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_proxy_meeting_8574.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Panoramica delle direttive e dei valori indicativi<\/h2>\n<p>Imposto in modo mirato i parametri chiave per controllare la memoria e il comportamento di trasmissione. Il primo buffer per le intestazioni di risposta \u00e8 collegato a <strong>proxy_buffer_size<\/strong>; impedisce errori di header eccessivamente grandi ed evita inutili operazioni di paging. Distribuisco i dati effettivi della risposta tramite <strong>proxy_buffers<\/strong> come coppie numero-per-dimensione, in modo che i body rimangano interamente nella RAM, per quanto realisticamente possibile. Con <strong>proxy_busy_buffers_size<\/strong> Limito la quantit\u00e0 di buffer gi\u00e0 destinati alla trasmissione, per contenere il consumo di memoria attiva. Per stabilire le dimensioni tipiche, mi baso sulle pagine di memoria (4\u201332 KB) e sui profili di risposta noti delle mie applicazioni.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th><strong>direttiva<\/strong><\/th>\n      <th><strong>Effetto<\/strong><\/th>\n      <th><strong>Valori tipici<\/strong><\/th>\n      <th><strong>Note<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>proxy_buffering<\/td>\n      <td><strong>On\/Off<\/strong> della memorizzazione temporanea<\/td>\n      <td>on (impostazione predefinita)<\/td>\n      <td>Lasciare attivo per le applicazioni web standard; verificare per lo streaming in diretta<\/td>\n    <\/tr>\n    <tr>\n      <td>proxy_buffer_size<\/td>\n      <td><strong>Buffer di intestazione<\/strong><\/td>\n      <td>8k\u201316k<\/td>\n      <td>Se \u00e8 troppo piccolo, si verifica l'errore \u201eupstream sent too big header\u201c<\/td>\n    <\/tr>\n    <tr>\n      <td>proxy_buffers<\/td>\n      <td><strong>Buffer del corpo<\/strong><\/td>\n      <td>8 da 16k, 16 da 16k<\/td>\n      <td>Collegare alle dimensioni della risposta e al parallelismo<\/td>\n    <\/tr>\n    <tr>\n      <td>proxy_busy_buffers_size<\/td>\n      <td><strong>Limite del buffer di trasmissione<\/strong><\/td>\n      <td>32k\u2013128k<\/td>\n      <td>Una larghezza di banda sufficiente, senza occupare RAM<\/td>\n    <\/tr>\n    <tr>\n      <td>proxy_max_temp_file_size<\/td>\n      <td><strong>Limite del disco<\/strong><\/td>\n      <td>0\u20131 g<\/td>\n      <td>0 disattiva i file temporanei<\/td>\n    <\/tr>\n    <tr>\n      <td>proxy_temp_path<\/td>\n      <td><strong>Percorso<\/strong> per i file temporanei<\/td>\n      <td>Percorso SSD<\/td>\n      <td>Salvare su un supporto di memorizzazione veloce<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Profili orientati alla pratica ed esempi di calcolo<\/h2>\n<p>Calcolo approssimativamente lo spazio di memoria richiesto per ogni connessione attiva come somma di <strong>proxy_buffer_size<\/strong> pi\u00f9 (N \u00d7 dimensione del buffer) da proxy_buffers. Con 8 buffer da 16k pi\u00f9 16k di header, si arriva a circa 144 KB per ogni richiesta, purch\u00e9 tutto rimanga nella RAM. Con 5.000 richieste simultanee, calcolo quindi circa 720 MB di occupazione pura del buffer, pi\u00f9 l'overhead del <strong>Processi<\/strong>. Se il traffico aumenta, aumenta anche la domanda: per questo definisco le dimensioni del buffer in modo che le risposte tipiche siano adeguate, senza considerare come casi normali quelle anomale con corpi di dimensioni eccessive. Ove necessario, limito le eccezioni con <strong>Limiti del disco<\/strong>, per far fronte ai picchi di consumo.<\/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-proxy-optimization-4285.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Quando disattivo intenzionalmente il buffering<\/h2>\n<p>Le API in tempo reale, gli eventi inviati dal server o i video in diretta richiedono un collegamento diretto <strong>Produttivit\u00e0<\/strong> senza bufferizzazione aggiuntiva. In questi casi disattivo proxy_buffering e puntano su un\u2019efficiente <strong>Streaming<\/strong>. Il proxy inoltra quindi immediatamente i dati, evitando picchi di latenza per i dati in tempo reale, ma mantenendo aperta pi\u00f9 a lungo la connessione al backend. Per questi modelli, vale la pena dare un\u2019occhiata a <a href=\"https:\/\/webhosting.de\/it\/risposta-http-streaming-hosting-performance-chunks\/\">Risposta in streaming<\/a>, compresa un'adeguata regolazione dei valori di keepalive e timeout. \u00c8 importante tenere sotto controllo il maggiore consumo di risorse per ogni connessione e impostare i limiti di conseguenza.<\/p>\n\n<h2>Impostare i buffer occupati in modo mirato<\/h2>\n<p>Con <strong>proxy_busy_buffers_size<\/strong> Controllo la quantit\u00e0 di memoria \u201epronta per l\u2019invio\u201c che rimane bloccata contemporaneamente. Se il limite \u00e8 troppo basso, la distribuzione rallenta; se \u00e8 troppo alto, aumentano i picchi di RAM. Scelgo quindi un valore pari a 1\u20132 volte la dimensione del buffer, in modo che NGINX inoltri i pacchetti rapidamente senza consumare troppa <strong>Memoria<\/strong> da allocare. Per i client lenti, accetto un po\u2019 pi\u00f9 di spazio di lavoro per ridurre il rischio di frequenti cambi di contesto. Le reti veloci traggono vantaggio da valori pi\u00f9 ridotti, che <strong>Requisiti di memoria<\/strong> mantenere la pianificabilit\u00e0.<\/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_proxy_buffering_opt_7823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>File temporanei: percorso, dimensione, limiti<\/h2>\n<p>Attivo le <strong>File<\/strong> solo quando i body di grandi dimensioni vengono visualizzati in modo realistico o la RAM \u00e8 insufficiente. Se i file temporanei si trovano su un SSD, i tempi di risposta rimangono accettabili; su un disco lento, le operazioni di I\/O rallentano rapidamente l'intero <strong>Catena di risposte<\/strong>. Con `proxy_max_temp_file_size` mi proteggo da un utilizzo eccessivo dello spazio; in caso di dubbio, imposta un limite rigido. Se si verificano molte risposte grandi in parallelo, prevedo spazio sufficiente e monitoro l\u2019utilizzo effettivo. Laddove \u00e8 disponibile RAM, preferisco buffer pi\u00f9 grandi e mantengo le parti critiche nel <strong>Memoria<\/strong>.<\/p>\n\n<h2>Ottimizzazione iterativa, metriche e test<\/h2>\n<p>Inizio con i conservatori <strong>Valori<\/strong>, misura, regola e ripeti il ciclo. Le metriche importanti sono la latenza, il tasso di errore, i picchi di RAM, i tempi di attesa I\/O e il carico di lavoro della <strong>Lavoratore<\/strong>. I test di carico mettono in luce effetti che nella routine quotidiana passano inosservati, come i picchi nelle intestazioni causati dai cookie o le rare mega-risposte. Inoltre, regolo i parametri di connessione e dei worker in modo coordinato, ad esempio <a href=\"https:\/\/webhosting.de\/it\/nginx-connessioni-dei-worker-scalabilita-di-migliaia-di-richieste-aumento-del-traffico\/\">Worker\u2011Connections<\/a> e Keepalive. Controllo ogni modifica in modo mirato, in modo da valutare l'impatto della <strong>Buffer<\/strong> pu\u00f2 attribuire chiaramente.<\/p>\n\n<h2>Buffering delle richieste e caricamenti<\/h2>\n<p>I buffer di risposta rappresentano solo met\u00e0 della verit\u00e0. Sul lato di ingresso, controlla <strong>proxy_request_buffering<\/strong>, se NGINX memorizza temporaneamente i corpi dei client (ad es. i file caricati) fino al completamento o li trasmette immediatamente all\u2019upstream. Per le API che ricevono file di grandi dimensioni, spesso disattivo il buffer di richiesta: l\u2019upstream vede il flusso prima, i timeout diminuiscono e NGINX non deve memorizzare temporaneamente sul disco body di grandi dimensioni. Lo svantaggio: la connessione upstream rimane aperta pi\u00f9 a lungo ed \u00e8 pi\u00f9 dipendente dalla velocit\u00e0 del client. Per i moduli classici o le richieste JSON pi\u00f9 piccole, il buffering delle richieste rimane attivo per smussare correttamente i picchi e controllare meglio le risorse del server. Lo combino con <strong>dimensione_cliente_max_corpo<\/strong> e una corrispondente <strong>client_body_buffer_size<\/strong>, in modo che i valori anomali vengano scartati tempestivamente o adeguatamente attenuati.<\/p>\n\n<h2>Controllo di Pro-Response: X-Accel-Buffering, Chunked e lunghezze<\/h2>\n<p>A livello di granularit\u00e0 fine, disattivo il buffering per ogni risposta tramite <strong>X-Accel-Buffering<\/strong> Dall'upstream: l'header \u201eX-Accel-Buffering: no\u201c indica a NGINX di trasmettere la risposta in streaming direttamente, anche se proxy_buffering \u00e8 attivo a livello globale. Lo utilizzo per SSE, long-polling o flussi di diagnostica, senza compromettere l'ottimizzazione generale. Inoltre, mi assicuro che sia corretto <strong>Lunghezza contenuto<\/strong>, ove possibile: se NGINX conosce la lunghezza, pianifica i buffer e i file temporanei in modo pi\u00f9 prevedibile rispetto a quando si utilizza esclusivamente <strong>spezzettato<\/strong> viene trasmesso. Se la lunghezza \u00e8 sconosciuta (ad es. nei live stream), valuto il fabbisogno in modo prudente e garantisco l\u2019I\/O con dei limiti. Per le pagine di errore o le risposte JSON di piccole dimensioni, mantengo il buffering rigorosamente attivo, in modo che il collegamento a monte venga liberato tempestivamente.<\/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_proxy_optimization_7381.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Compressione e protocolli: HTTP\/2\/3 in primo piano<\/h2>\n<p>La compressione e il buffering vanno considerati insieme. Se <strong>gzip<\/strong> oppure con Brotli attivo, la compressione trae vantaggio dai blocchi di dati contigui presenti nella RAM. I buffer troppo piccoli possono limitare la velocit\u00e0 effettiva, poich\u00e9 il compressore deve cambiare contesto pi\u00f9 frequentemente. Scelgo quindi dimensioni dei buffer che raggruppino bene i segmenti di risposta tipici, senza far traboccare la RAM per ogni connessione. Sotto <strong>HTTP\/2<\/strong> e <strong>HTTP\/3<\/strong> Con il multiplexing e il controllo di flusso, la velocit\u00e0 di invio varia a seconda dello stream; il buffering stabilizza il lato backend, mentre NGINX sincronizza gli stream in modo preciso. Importante: su percorsi molto sensibili alla latenza, ridurre di un tick il \u201ebusy space\u201c pu\u00f2 aiutare a mitigare gli effetti \u00abhead-of-line\u00bb; su linee \u00abpotenti\u00bb con finestre ampie, libero un po\u2019 pi\u00f9 di \u00abbusy space\u00bb per mantenere la massima velocit\u00e0 di trasmissione.<\/p>\n\n<h2>Cache del proxy e richieste di intervallo: interazione con i buffer<\/h2>\n<p>Chi <strong>proxy_cache<\/strong> Se si utilizza questa configurazione, \u00e8 necessario coordinare il budget per i buffer e i file temporanei. NGINX pu\u00f2 memorizzare nella cache le risposte e distribuirle ai client contemporaneamente; una quantit\u00e0 sufficiente di buffer RAM riduce la durata della connessione al backend, mentre l\u2019hit della cache disaccoppia completamente le richieste successive. Limito i file temporanei in modo pi\u00f9 rigoroso quando la cache \u00e8 \"calda\" e li apro finch\u00e9 \u00e8 in corso l'accumulo del tasso di hit. In caso di <strong>Richieste relative alla gamma<\/strong> (Download parziali) decido se servirli direttamente dalla cache o se lasciarli prima caricare completamente nel buffer. Le richieste frequenti di file di grandi dimensioni traggono vantaggio da dimensioni del buffer calibrate con precisione e da risposte segmentate (opzionali), in modo che n\u00e9 l'I\/O su disco n\u00e9 la RAM vadano fuori controllo.<\/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-optimierung-server-4573.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Client lenti: ottimizzare la velocit\u00e0 di trasmissione senza sovraccaricare la RAM<\/h2>\n<p>Gran parte degli effetti di buffer si manifesta solo con client molto lenti. Io impiego <strong>send_timeout<\/strong> e opzionale <strong>limit_rate<\/strong>\/<strong>tasso_limite_dopo<\/strong>, per proteggere i destinatari lenti senza occupare eccessivamente i worker. In caso di forte limitazione della larghezza di banda, i buffer \u201cbusy\u201d devono aumentare, altrimenti si rischia il blocco del sistema; allo stesso tempo, controllo il numero di connessioni parallele per IP per mitigare i modelli anomali. Per i download con una clientela eterogenea (rete mobile, Wi-Fi, fibra ottica), valori moderati di \"busy\" e buffer \"body\" leggermente pi\u00f9 generosi aiutano NGINX a inviare i dati in modo lineare, mentre l\u2019upstream \u00e8 gi\u00e0 impegnato con la richiesta successiva.<\/p>\n\n<h2>Operativit\u00e0 in container e orchestrazione<\/h2>\n<p>Lo pianifico nei contenitori <strong>proxy_temp_path<\/strong> Da tenere presente: o un volume host veloce (SSD) oppure un tmpfs, se \u00e8 disponibile RAM a sufficienza. I limiti dei container (memoria\/CPU\/memoria temporanea) influiscono direttamente sui buffer e sui file temporanei; mantengo un margine sufficiente per i picchi e regolo di conseguenza il numero di worker e connessioni in parallelo. Rimangono importanti <strong>ulimit -n<\/strong> (descrittori di file) e le quote dell\u2019Orchestrator: se la memoria effimera \u00e8 troppo piccola, i file temporanei generano errori; se la RAM \u00e8 insufficiente, i worker si bloccano a causa della pressione OOM. Dimensiono i buffer in modo tale che i picchi di carico tipici rimangano stabili entro i limiti del container e monitoro costantemente lo spazio effettivamente occupato dalle directory temporanee.<\/p>\n\n<h2>Impostazioni iniziali e modello per le app web pi\u00f9 diffuse<\/h2>\n<p>Come punto di partenza attendibile utilizzo un breve profilo, che poi affino con i valori misurati. Esempio:<\/p>\n<pre><code>location \/ {\n    proxy_http_version 1.1;\n    proxy_set_header Connection \"\";\n    proxy_buffering on;\n\n    Buffer di intestazione e corpo #\n    proxy_buffer_size 16k;\n    proxy_buffers 16 16k;\n    proxy_busy_buffers_size 64k;\n\n    # File temporanei solo come soluzione di ripiego\n    proxy_max_temp_file_size 256m;\n    proxy_temp_path \/var\/cache\/nginx\/proxy_temp 1 2;\n\n    # Timeout e invio\n    proxy_read_timeout 60s;\n    send_timeout 30s;\n\n # Opzionale: streaming in upload a seconda dell'API\n    # proxy_request_buffering off;\n}\n<\/code><\/pre>\n<p>In questo modo, le risposte di media lunghezza rimangono interamente nella RAM, l\u2019upstream viene liberato tempestivamente e i file temporanei vengono utilizzati solo in caso di valori anomali. Nella seconda fase, adeguo il numero di buffer al parallelismo effettivo; se necessario, in caso di risposte brevi e frequenti, aumento leggermente la dimensione del \"busy\" e limito maggiormente i file temporanei non appena il tasso di hit della cache diventa significativo.<\/p>\n\n<h2>Monitoraggio e registrazione: rendere visibili gli effetti<\/h2>\n<p>Misuro con costanza: <strong>$request_time<\/strong> e <strong>$upstream_response_time<\/strong> nell'access log \u00e8 possibile verificare se l'upstream viene disaccoppiato prematuramente. <strong>1 TP 4 TB inviati<\/strong> e <strong>$body_bytes_sent<\/strong> aiutano ad allineare i profili del buffer al traffico reale. Se la differenza tra il tempo upstream e la durata totale diminuisce, i buffer funzionano correttamente. Metto in relazione questo fenomeno con i picchi di RAM, l\u2019attesa I\/O e l\u2019occupazione del <strong>proxy_temp_path<\/strong>. Nei test di stress vario la velocit\u00e0 dei client, l\u2019altezza delle risposte e il carico delle intestazioni (ad es. i cookie) per individuare i casi limite. Solo quando le metriche dei log e i valori di sistema si attestano stabilmente all\u2019interno del mio intervallo target, congelo il profilo e documento i limiti e i percorsi di escalation (buffer pi\u00f9 grandi, politica dei file temporanei diversa, repliche aggiuntive).<\/p>\n\n<h2>Errori comuni e relative soluzioni<\/h2>\n<p>Il messaggio \u201e<strong>l'header inviato a monte \u00e8 troppo grande<\/strong>\u201cLo risolvo aumentando il valore di `proxy_buffer_size` e, se necessario, aumentando la dimensione dei `proxy_buffers`. Se si verificano timeout con dispositivi terminali lenti, aumento moderatamente i timeout di invio e lascio un po\u2019 di margine ai buffer occupati. Se la directory temporanea si riempie, riduco la dimensione massima o aumento i buffer RAM, a seconda del rapporto costi-benefici. Se la distribuzione risulta a scatti, verifico eventuali colli di bottiglia nell\u2019I\/O, la saturazione della CPU e la distribuzione dei <strong>Buffer<\/strong>. Quando si verificano situazioni di scarsit\u00e0, mi baso sempre innanzitutto sui dati di misura, non su raddoppi generici.<\/p>\n\n<h2>Conclusione: i miei punti di controllo per il buffering del proxy NGINX<\/h2>\n<p>Per prima cosa definisco i tipici <strong>Dimensioni della risposta<\/strong>, picchi di carico e profili client, prima ancora di impostare i buffer. Successivamente, imposto un buffer di intestazione sufficientemente grande per evitare errori inutili. Dimensiono i buffer del corpo in modo che le risposte standard rimangano nella RAM e solo le eccezioni vengano trasferite su <strong>Disco<\/strong> cadono. Configuro i \"Busy Buffers\" in modo che i trasferimenti avvengano in modo fluido, senza sprecare memoria. Infine, verifico il tutto con test di carico e monitoraggio, finch\u00e9 la latenza, la velocit\u00e0 di trasmissione e il fabbisogno di memoria non raggiungono un livello affidabile <strong>Finestre<\/strong> bugia.<\/p>","protected":false},"excerpt":{"rendered":"<p>Spiegazione del buffering del proxy NGINX: come ottimizzare le prestazioni, l'utilizzo della memoria e la configurazione del reverse proxy nella pratica.<\/p>","protected":false},"author":1,"featured_media":21144,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-21151","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":"131","_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 Buffering","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":"21144","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21151","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=21151"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21151\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/21144"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=21151"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=21151"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=21151"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}