{"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-buffering-ydeevne-hukommelse-proxy","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/nginx-buffering-performance-speicher-proxy\/","title":{"rendered":"NGINX-proxybuffering: Optimering af ydeevne og hukommelse"},"content":{"rendered":"<p><strong>NGINX-buffering<\/strong> bestemmer, hvor hurtigt og med hvor lidt belastning p\u00e5 hukommelsen din proxy modtager svar fra upstream, lagrer dem i bufferen og sender dem videre til klienterne. Jeg viser, hvordan jeg reducerer latenstiden, frigiver backend-forbindelser tidligt og <strong>Hukommelse<\/strong> holde det under kontrol.<\/p>\n\n<h2>Centrale punkter<\/h2>\n<p>F\u00f8lgende centrale aspekter hj\u00e6lper mig med at finde den rette balance mellem ydeevne og hukommelsesforbrug.<\/p>\n<ul>\n  <li><strong>Afkobling<\/strong> mellem klient og backend reducerer forbindelsestiden og \u00f8ger gennemstr\u00f8mningen.<\/li>\n  <li><strong>Bufferst\u00f8rrelser<\/strong> V\u00e6lg \u00bbexakt\u00ab for at spare RAM og undg\u00e5 disk-I\/O.<\/li>\n  <li><strong>optagede buffere<\/strong> begr\u00e6nse den aktive hukommelse under transmissionen.<\/li>\n  <li><strong>Undtagelser vedr\u00f8rende streaming<\/strong> bruge det uden buffering.<\/li>\n  <li><strong>Overv\u00e5gning<\/strong> og belastningstests sikrer, at alle \u00e6ndringer fungerer korrekt.<\/li>\n<\/ul>\n\n<h2>S\u00e5dan fungerer proxy-buffering i NGINX<\/h2>\n<p>Jeg bruger aktivt <strong>Buffering<\/strong>, s\u00e5 NGINX hurtigt kan indhente svar fra upstream og derefter selvst\u00e6ndigt levere dem til klienterne. Denne adskillelse reducerer <strong>Forsinkelse<\/strong> p\u00e5 backend-siden, fordi applikationen bliver f\u00e6rdig hurtigere og lukker sin forbindelse tidligere. Mens klienter indl\u00e6ses med varierende hastighed, regulerer proxylaget udsendelsen fra RAM-hukommelsen. Hvis dataene ikke kan v\u00e6re i RAM, kan NGINX midlertidigt bruge filer og dermed stadig videresende svaret p\u00e5lideligt. Netop denne adf\u00e6rd stabiliserer st\u00e6rkt belastede systemer med mange samtidige <strong>Forbindelser<\/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>Hvorn\u00e5r er aktiv buffering det bedste valg?<\/h2>\n<p>Ved klassiske webapps, API\u2019er med mellemstore svarst\u00f8rrelser eller WordPress-stacks leverer <strong>Buffering<\/strong> giver regelm\u00e6ssigt de bedste resultater. Jeg aflaster backendet tidligere, mens NGINX overtager den resterende overf\u00f8rsel til ofte blandede klientnetv\u00e6rk. Dermed \u00f8ges den effektive <strong>Gennemstr\u00f8mning<\/strong>, is\u00e6r n\u00e5r der k\u00f8rer mange anmodninger samtidigt. Hvis man samler flere tjenester bag en reverse proxy, f\u00e5r man desuden fordel af den kontrollerede belastningsfordeling. N\u00e5r det g\u00e6lder arkitektursp\u00f8rgsm\u00e5l vedr\u00f8rende proxyer, hj\u00e6lper en klar <a href=\"https:\/\/webhosting.de\/da\/reverse-proxy-opsaetninger-webhosting-arkitektur-proxyhosting\/\">Omvendt proxy-arkitektur<\/a>, der skelner klart mellem roller og begr\u00e6nsninger.<\/p>\n\n<h2>Hukommelse vs. I\/O: det rigtige budget<\/h2>\n<p>Jeg afbalancerer RAM og harddiskadgang, fordi for sm\u00e5 buffere medf\u00f8rer un\u00f8dvendige <strong>Disk-I\/O<\/strong> udl\u00f8se, og for store buffere \u00f8ger hukommelsesforbruget pr. forbindelse. De afg\u00f8rende faktorer er typiske svarst\u00f8rrelser, parallelle foresp\u00f8rgsler og den faktiske <strong>Klienthastighed<\/strong>. Sm\u00e5 svar forbliver ideelt set helt i RAM, hvilket g\u00f8r, at NGINX kan streame dem til langsommere modtagere uden ventetid. Meget store indholdsdele m\u00e5 gerne gemmes p\u00e5 disken, men i s\u00e5 fald s\u00f8rger jeg for hurtige drev og s\u00e6tter gr\u00e6nser for at undg\u00e5 overdreven I\/O. Denne balance opretholder <strong>Svartider<\/strong> lavt og beskytter systemet mod tryk i beholderen.<\/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>Oversigt over direktiver og vejledende v\u00e6rdier<\/h2>\n<p>Jeg indstiller de centrale parametre m\u00e5lrettet for at styre cachelagring og sendningsadf\u00e6rd. Den f\u00f8rste buffer til svarheaderne er knyttet til <strong>proxy_buffer_size<\/strong>; det forhindrer for store header-fejl og undg\u00e5r un\u00f8dvendige udlagringer. Selve svardataene fordeler jeg via <strong>proxy_buffers<\/strong> som par best\u00e5ende af antal og st\u00f8rrelse, s\u00e5 bodier forbliver fuldst\u00e6ndigt i RAM, i det omfang det er realistisk. Med <strong>proxy_busy_buffers_size<\/strong> Jeg begr\u00e6nser m\u00e6ngden af buffere, der allerede er reserveret til afsendelse, for at d\u00e6mpe det aktive hukommelsesforbrug. De typiske st\u00f8rrelser baserer jeg p\u00e5 hukommelsessider (4\u201332 KB) og de kendte svarprofiler for mine applikationer.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th><strong>direktiv<\/strong><\/th>\n      <th><strong>Effekt<\/strong><\/th>\n      <th><strong>Typiske v\u00e6rdier<\/strong><\/th>\n      <th><strong>Noter<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>proxy_buffering<\/td>\n      <td><strong>T\u00e6nd\/Sluk<\/strong> af bufferen<\/td>\n      <td>p\u00e5 (standard)<\/td>\n      <td>Lad den v\u00e6re aktiveret for standard-webapps; kontroller for live-streaming<\/td>\n    <\/tr>\n    <tr>\n      <td>proxy_buffer_size<\/td>\n      <td><strong>Header-buffer<\/strong><\/td>\n      <td>8k\u201316k<\/td>\n      <td>For lille st\u00f8rrelse medf\u00f8rer fejlen \u201eupstream sent too big header\u201c<\/td>\n    <\/tr>\n    <tr>\n      <td>proxy_buffers<\/td>\n      <td><strong>Kropsst\u00f8tte<\/strong><\/td>\n      <td>8 \u00d7 16k, 16 \u00d7 16k<\/td>\n      <td>Koble til svarst\u00f8rrelser og parallelitet<\/td>\n    <\/tr>\n    <tr>\n      <td>proxy_busy_buffers_size<\/td>\n      <td><strong>Gr\u00e6nse for sendepuffer<\/strong><\/td>\n      <td>32k\u2013128k<\/td>\n      <td>Tilstr\u00e6kkelig gennemstr\u00f8mning uden at optage RAM<\/td>\n    <\/tr>\n    <tr>\n      <td>proxy_max_temp_file_size<\/td>\n      <td><strong>Disk-begr\u00e6nsning<\/strong><\/td>\n      <td>0\u20131 g<\/td>\n      <td>0 deaktiverer midlertidige filer<\/td>\n    <\/tr>\n    <tr>\n      <td>proxy_temp_path<\/td>\n      <td><strong>Sti<\/strong> til midlertidige filer<\/td>\n      <td>SSD-sti<\/td>\n      <td>Gem p\u00e5 et hurtigt lagringsmedie<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Praksisorienterede profiler og regneeksempler<\/h2>\n<p>Jeg beregner groft lagerbehovet pr. aktiv forbindelse som summen af <strong>proxy_buffer_size<\/strong> plus (N \u00d7 bufferst\u00f8rrelse) fra proxy_buffers. Med 8 stk. 16 k plus 16 k header ender vi p\u00e5 ca. 144 KB pr. anmodning, s\u00e5 l\u00e6nge alt forbliver i RAM\u2019en. Ved 5.000 samtidige anmodninger regner jeg derfor med ca. 720 MB ren bufferbel\u00e6gning plus overhead fra <strong>Processer<\/strong>. N\u00e5r trafikken stiger, stiger behovet ogs\u00e5 \u2013 derfor fasts\u00e6tter jeg buffere p\u00e5 en s\u00e5dan m\u00e5de, at typiske svar passer ind, uden at us\u00e6dvanlige tilf\u00e6lde med overdrevent store br\u00f8dtekster bliver normen. Hvor det er n\u00f8dvendigt, begr\u00e6nser jeg undtagelser med <strong>Diskbegr\u00e6nsninger<\/strong>, for at udj\u00e6vne spidsbelastninger i lageret.<\/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>Hvorn\u00e5r jeg bevidst sl\u00e5r buffering fra<\/h2>\n<p>Realtids-API\u2019er, server-sent events eller livevideo kr\u00e6ver direkte <strong>Gennemstr\u00f8mning<\/strong> uden yderligere buffering. I s\u00e5danne tilf\u00e6lde deaktiverer jeg proxy_buffering og satser p\u00e5 effektiv <strong>Streaming<\/strong>. Proxyserveren videresender derefter dataene med det samme, hvilket undg\u00e5r forsinkelsestoppe for live-data, men holder backend-forbindelsen \u00e5ben i l\u00e6ngere tid. I forbindelse med disse m\u00f8nstre er det v\u00e6rd at se n\u00e6rmere p\u00e5 <a href=\"https:\/\/webhosting.de\/da\/http-svar-streaming-hosting-performance-chunks\/\">Streaming af svar<\/a>, herunder fornuftig justering af keepalive og timeout. Det er vigtigt at holde \u00f8je med det h\u00f8jere ressourceforbrug pr. forbindelse og fasts\u00e6tte gr\u00e6nser i overensstemmelse hermed.<\/p>\n\n<h2>M\u00e5lrettet indstilling af Busy Buffers<\/h2>\n<p>Med <strong>proxy_busy_buffers_size<\/strong> Her styrer jeg, hvor meget af den \u201eafsendeklare\u201c hukommelse der forbliver blokeret p\u00e5 samme tid. Er bremsen sat for lavt, g\u00e5r leveringen i st\u00e5; er den sat for h\u00f8jt, stiger RAM-spidsbelastningerne. Jeg v\u00e6lger derfor en v\u00e6rdi, der svarer til 1\u20132 gange bufferst\u00f8rrelsen, s\u00e5 NGINX hurtigt kan sende pakkerne videre uden at bruge for meget <strong>Hukommelse<\/strong> at binde. For langsomme klienter accepterer jeg lidt mere \u00bbbusy-space\u00ab for at mindske risikoen for hyppige kontekstskift. Hurtige netv\u00e6rk drager fordel af lavere v\u00e6rdier, som <strong>Krav til hukommelse<\/strong> holde det inden for rammerne af det planlagte.<\/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>Midlertidige filer: Sti, st\u00f8rrelse, begr\u00e6nsninger<\/h2>\n<p>Jeg aktiverer midlertidige <strong>Filer<\/strong> kun hvis store dataobjekter forekommer i praksis, eller hvis der er knap med RAM. Hvis midlertidige filer ligger p\u00e5 en SSD, forbliver responstiderne acceptable; p\u00e5 en langsom harddisk bremser I\/O hurtigt hele <strong>Svartr\u00e5d<\/strong>. Med `proxy_max_temp_file_size` beskytter jeg mig mod overdreven belastning; i tvivlstilf\u00e6lde s\u00e6tter jeg en fast gr\u00e6nse. Hvis der forekommer mange store svar samtidigt, afs\u00e6tter jeg tilstr\u00e6kkelig plads og overv\u00e5ger den faktiske udnyttelse. Hvor der er RAM til r\u00e5dighed, foretr\u00e6kker jeg st\u00f8rre buffere og opbevarer kritiske dele i <strong>Hukommelse<\/strong>.<\/p>\n\n<h2>Iterativ finjustering, m\u00e5linger og test<\/h2>\n<p>Jeg starter med konservativ <strong>V\u00e6rdier<\/strong>, m\u00e5l, juster og gentag cyklussen. Vigtige m\u00e5lepunkter er latenstid, fejlprocent, RAM-spidsbelastninger, I\/O-ventetider og udnyttelse af <strong>Arbejder<\/strong>. Belastningstests afsl\u00f8rer effekter, der gemmer sig i hverdagen, f.eks. spidsbelastninger i headeren p\u00e5 grund af cookies eller sj\u00e6ldne mega-responser. Derudover justerer jeg forbindelses- og worker-parametre i samspil, f.eks. <a href=\"https:\/\/webhosting.de\/da\/nginx-worker-forbindelser-skalering-af-tusindvis-af-anmodninger-trafficboost\/\">Arbejdstagerforbindelser<\/a> og Keepalive. Jeg gennemg\u00e5r hver \u00e6ndring n\u00f8je for at vurdere indvirkningen af <strong>Buffer<\/strong> kan klart henf\u00f8res til.<\/p>\n\n<h2>Request-buffering og uploads<\/h2>\n<p>Svarbuffere er kun halvdelen af sandheden. P\u00e5 indgangssiden styrer <strong>proxy_request_buffering<\/strong>, om NGINX f\u00f8rst bufferer klient-body\u2019er (f.eks. uploads) fuldst\u00e6ndigt eller straks streamer dem til upstream. For API\u2019er, der modtager store filer, sl\u00e5r jeg ofte request-buffering fra: Upstream-serveren ser datastr\u00f8mmen tidligere, timeouts reduceres, og NGINX beh\u00f8ver ikke at gemme store data p\u00e5 disken midlertidigt. Ulempen er, at forbindelsen til upstream-serveren forbliver \u00e5ben l\u00e6ngere og er mere afh\u00e6ngig af klientens hastighed. Ved klassiske formularer eller mindre JSON-anmodninger forbliver anmodningsbuffering aktiveret for at udj\u00e6vne spidsbelastninger og bedre kontrollere serverressourcerne. Jeg kombinerer dette med <strong>klient_max_kropsst\u00f8rrelse<\/strong> og en passende <strong>client_body_buffer_size<\/strong>, s\u00e5 afvigende v\u00e6rdier afvises tidligt eller bufferes p\u00e5 en fornuftig m\u00e5de.<\/p>\n\n<h2>Styring af Pro-Response: X-Accel-Buffering, chunked og l\u00e6ngder<\/h2>\n<p>For finindstilling sl\u00e5r jeg buffering pr. svar til via <strong>X-Accel-buffering<\/strong> Fra upstream: Headeren \u201eX-Accel-Buffering: no\u201c signalerer til NGINX, at svaret skal streames direkte, selvom proxy_buffering er aktiveret globalt. Det bruger jeg til SSE, long-polling eller diagnostiske streams uden at g\u00e5 p\u00e5 kompromis med den generelle optimering. Derudover s\u00f8rger jeg for, at <strong>Indholdsl\u00e6ngde<\/strong>, hvor det er muligt: Hvis NGINX kender l\u00e6ngden, kan det planl\u00e6gge buffere og midlertidige filer p\u00e5 en mere forudsigelig m\u00e5de, end hvis man udelukkende <strong>i bidder<\/strong> overf\u00f8res. Hvis l\u00e6ngden er ukendt (f.eks. live-streams), estimerer jeg behovet konservativt og sikrer I\/O med begr\u00e6nsninger. For fejlsider eller sm\u00e5 JSON-svar lader jeg buffering v\u00e6re strengt aktiveret, s\u00e5 upstream-forbindelsen frig\u00f8res tidligt.<\/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>Komprimering og protokoller: HTTP\/2\/3 i fokus<\/h2>\n<p>Komprimering og buffering skal betragtes som en helhed. Er <strong>gzip<\/strong> eller n\u00e5r Brotli er aktiv, drager komprimeringen fordel af sammenh\u00e6ngende datablokke i RAM\u2019en. For sm\u00e5 buffere kan begr\u00e6nse gennemstr\u00f8mningen, fordi kompressoren oftere er n\u00f8dt til at skifte kontekst. Jeg v\u00e6lger derfor bufferst\u00f8rrelser, der samler typiske svarsegmenter godt, uden at RAM'en bliver overbelastet pr. forbindelse. Under <strong>HTTP\/2<\/strong> og <strong>HTTP\/3<\/strong> Med multiplexing og flowkontrol varierer afsendelseshastigheden fra stream til stream; buffering stabiliserer backend-siden, mens NGINX sikrer en j\u00e6vn afsendelse af streamene. Vigtigt: P\u00e5 meget latenstf\u00f8lsomme forbindelser kan en smule mindre busy-space hj\u00e6lpe med at afb\u00f8de head-of-line-effekter; p\u00e5 \u201ekraftige\u201c forbindelser med store vinduer frigiver jeg lidt mere busy-space for at opretholde maksimal sendekapacitet.<\/p>\n\n<h2>Proxy-cache og range-anmodninger: Samspil med buffere<\/h2>\n<p>Hvem <strong>proxy_cache<\/strong> b\u00f8r budgettet for buffere og midlertidige filer afstemmes i forhold til hinanden. NGINX kan cache svar og levere dem til klienter samtidigt; tilstr\u00e6kkelige RAM-buffere forkorter herved varigheden af backend-forbindelsen, mens cache-hit helt afkobler senere anmodninger. Jeg begr\u00e6nser midlertidige filer strengere, n\u00e5r cachen er varm, og \u00e5bner dem, s\u00e5 l\u00e6nge hitraten er under opbygning. Ved <strong>Foresp\u00f8rgsler om r\u00e6kkevidde<\/strong> (Delvise downloads) beslutter jeg, om jeg skal levere dem direkte fra cachen eller f\u00f8rst lade dem bufferes fuldt ud. Hyppige r\u00e6kker af store filer drager fordel af n\u00f8je afstemte bufferst\u00f8rrelser og eventuelt segmenterede svar, s\u00e5 hverken disk-I\/O eller RAM l\u00f8ber l\u00f8bsk.<\/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>Langsomme klienter: Begr\u00e6ns gennemstr\u00f8mningen uden at overbelaste RAM\u2019en<\/h2>\n<p>En stor del af buffereffekterne viser sig f\u00f8rst ved meget langsomme klienter. Jeg indstiller <strong>send_timeout<\/strong> og valgfrit <strong>limit_rate<\/strong>\/<strong>limit_rate_after<\/strong>, for at beskytte t\u00f8vende modtagere uden at binde worker-instanser un\u00f8digt. Hvis der begr\u00e6nses kraftigt, skal Busy-bufferne \u00f8ges, ellers er der risiko for systemnedbrud; samtidig overv\u00e5ger jeg antallet af parallelle forbindelser pr. IP-adresse for at afb\u00f8de unormale m\u00f8nstre. Ved downloads med blandede klienter (mobilnet, WLAN, fiber) hj\u00e6lper moderate busy-v\u00e6rdier og lidt mere gener\u00f8se body-buffere, s\u00e5 NGINX leverer line\u00e6rt, mens upstream allerede er optaget af den n\u00e6ste anmodning.<\/p>\n\n<h2>Drift i containere og orkestrering<\/h2>\n<p>Jeg planl\u00e6gger det i containere <strong>proxy_temp_path<\/strong> Bem\u00e6rk: Enten et hurtigt host-drev (SSD) eller et tmpfs, hvis der er tilstr\u00e6kkelig RAM til r\u00e5dighed. Containergr\u00e6nser (hukommelse\/CPU\/midlertidig lagerplads) p\u00e5virker direkte buffere og midlertidige filer; jeg s\u00f8rger for tilstr\u00e6kkelig reserve til spidsbelastninger og justerer antallet af parallelle arbejdsprocesser og forbindelser i overensstemmelse hermed. Det er stadig vigtigt at <strong>ulimit -n<\/strong> (fildeskriptorer) og Orchestrator-kvoter: Hvis den midlertidige hukommelse er for lille, resulterer det i fejl i tempfiler; hvis der er for lidt RAM, g\u00e5r arbejdsprocesser ned under OOM-pres. Jeg dimensionerer buffere, s\u00e5 typiske belastningstoppe forbliver stabile inden for containergr\u00e6nserne, og overv\u00e5ger l\u00f8bende det faktiske pladsbehov i de midlertidige mapper.<\/p>\n\n<h2>Startv\u00e6rdier og blueprint til almindelige webapps<\/h2>\n<p>Som et solidt udgangspunkt bruger jeg en kort profil, som jeg derefter pr\u00e6ciserer ved hj\u00e6lp af m\u00e5lev\u00e6rdier. Eksempel:<\/p>\n<pre><code>location \/ {\n    proxy_http_version 1.1;\n    proxy_set_header Connection \"\";\n    proxy_buffering on;\n\n    # Header- og body-buffer\n    proxy_buffer_size 16k;\n    proxy_buffers 16 16k;\n    proxy_busy_buffers_size 64k;\n\n    # Midlertidige filer kun som sikkerhedsnet\n    proxy_max_temp_file_size 256m;\n    proxy_temp_path \/var\/cache\/nginx\/proxy_temp 1 2;\n\n    # Timeouts og afsendelse\n    proxy_read_timeout 60s;\n    send_timeout 30s;\n\n # Valgfrit: Upload-streaming afh\u00e6ngigt af API\n    # proxy_request_buffering off;\n}\n<\/code><\/pre>\n<p>P\u00e5 den m\u00e5de forbliver mellemstore svar fuldt ud i RAM\u2019en, upstream frig\u00f8res tidligt, og midlertidige filer bruges kun ved afvigelser. I anden runde tilpasser jeg antallet af buffere til den faktiske parallelitet, \u00f8ger om n\u00f8dvendigt \u00bbbusy\u00ab-st\u00f8rrelsen en smule ved korte, hyppige svar og begr\u00e6nser midlertidige filer mere, s\u00e5 snart cache-hit-raten begynder at give resultater.<\/p>\n\n<h2>Overv\u00e5gning og logning: G\u00f8re effekten synlig<\/h2>\n<p>Jeg m\u00e5ler konsekvent: <strong>$request_time<\/strong> og <strong>$upstream_respons_tid<\/strong> i Access-loggen kan man se, om upstream-forbindelsen afbrydes tidligt. <strong>1 TP 4 Tbyte sendt<\/strong> og <strong>$body_bytes_sent<\/strong> hj\u00e6lper med at afstemme bufferprofiler med den faktiske trafik. Hvis forskellen mellem upstream-tiden og den samlede varighed mindskes, fungerer bufferne korrekt. Jeg s\u00e6tter dette i forbindelse med RAM-spidsbelastninger, I\/O-ventetid og udnyttelsen af <strong>proxy_temp_path<\/strong>. I stresstests varierer jeg klienthastigheder, svarh\u00f8jder og header-belastning (f.eks. cookies) for at finde gr\u00e6nsetilf\u00e6lde. F\u00f8rst n\u00e5r log-metrikker og systemv\u00e6rdier ligger stabilt inden for mit m\u00e5lomr\u00e5de, l\u00e5ser jeg profilen fast og dokumenterer gr\u00e6nser samt eskaleringsveje (st\u00f8rre buffere, anden temp-politik, yderligere replikaer).<\/p>\n\n<h2>Almindelige fejl og l\u00f8sninger herp\u00e5<\/h2>\n<p>Meddelelsen \u201e<strong>Der blev sendt en for stor header i upstream<\/strong>\u201c l\u00f8ser jeg ved at \u00f8ge proxy_buffer_size og, hvis n\u00f8dvendigt, antallet af proxy_buffers. Hvis der opst\u00e5r timeouts p\u00e5 langsomme enheder, \u00f8ger jeg sendetimeouts moderat og giver busy buffers lidt mere plads. Hvis temp-mappen fyldes op, s\u00e6nker jeg den maksimale st\u00f8rrelse eller \u00f8ger RAM-bufferne, afh\u00e6ngigt af en cost-benefit-vurdering. Hvis leveringen hakker, tjekker jeg for I\/O-flaskehalse, CPU-udnyttelse og fordelingen af <strong>Buffer<\/strong>. N\u00e5r der er mangel p\u00e5 noget, tager jeg altid f\u00f8rst udgangspunkt i m\u00e5linger og ikke i generelle fordoblinger.<\/p>\n\n<h2>Konklusion: Mine kontrolpunkter for NGINX-proxy-buffering<\/h2>\n<p>F\u00f8rst definerer jeg typiske <strong>St\u00f8rrelser p\u00e5 svar<\/strong>, spidsbelastning og klientprofiler, f\u00f8r jeg overhovedet justerer buffere. Derefter indstiller jeg en header-buffer, der er stor nok til, at jeg ikke f\u00e5r un\u00f8dvendige fejl. Jeg dimensionerer body-bufferne s\u00e5ledes, at almindelige svar forbliver i RAM\u2019en, og kun undtagelser skrives til <strong>Disk<\/strong> falde. Jeg indstiller Busy Buffers, s\u00e5 overf\u00f8rslerne foreg\u00e5r j\u00e6vnt uden at spilde hukommelse. Til sidst tester jeg det hele med belastningstests og overv\u00e5gning, indtil latenstid, gennemstr\u00f8mning og hukommelsesbehov ligger p\u00e5 et p\u00e5lideligt <strong>Vinduer<\/strong> l\u00f8gn.<\/p>","protected":false},"excerpt":{"rendered":"<p>NGINX-proxybuffering forklaret: S\u00e5dan optimerer du ydeevne, hukommelsesforbrug og reverse proxy-tuning i praksis.<\/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\/da\/wp-json\/wp\/v2\/posts\/21151","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/comments?post=21151"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21151\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/21144"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=21151"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=21151"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=21151"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}