{"id":20714,"date":"2026-08-16T18:19:23","date_gmt":"2026-08-16T16:19:23","guid":{"rendered":"https:\/\/webhosting.de\/nginx-worker-processes-optimal-konfigurieren-performanceboost\/"},"modified":"2026-08-16T18:19:23","modified_gmt":"2026-08-16T16:19:23","slug":"konfigurera-nginx-arbetsprocesser-optimalt-foer-baettre-prestanda","status":"publish","type":"post","link":"https:\/\/webhosting.de\/sv\/nginx-worker-processes-optimal-konfigurieren-performanceboost\/","title":{"rendered":"Optimera konfigurationen av NGINX-arbetsprocesser f\u00f6r maximal prestanda"},"content":{"rendered":"<p>Jag konfigurerar <strong>NGINX-arbetare<\/strong> s\u00e5 att worker_processes, worker_connections och worker_rlimit_nofile st\u00e4mmer exakt \u00f6verens och Epoll fungerar i h\u00e4ndelseslingan. P\u00e5 s\u00e5 s\u00e4tt anv\u00e4nder jag <strong>CPU-k\u00e4rnor<\/strong> Effektiv, m\u00f6jligg\u00f6r planerbar skalning av samtidiga anslutningar och h\u00e5ll latensen l\u00e5g vid belastningstoppar.<\/p>\n\n<h2>Centrala punkter<\/h2>\n<p>F\u00f6ljande nyckelaspekter ger dig omedelbar v\u00e4gledning f\u00f6r en stabil NGINX-Worker-konfiguration.<\/p>\n<ul>\n  <li><strong>arbetare_processer<\/strong> koppla till antalet logiska k\u00e4rnor, helst med \u201eauto\u201c.<\/li>\n  <li><strong>arbetare_anslutningar<\/strong> st\u00e4lla in s\u00e5 att verkliga toppar t\u00e4ckas utan problem.<\/li>\n  <li><strong>rlimit_nofile<\/strong> och h\u00f6ja OS-gr\u00e4nserna i enlighet med anslutningsvolymen.<\/li>\n  <li><strong>epoll<\/strong> och aktivera multi_accept f\u00f6r att utnyttja h\u00e4ndelseslingan effektivt.<\/li>\n  <li><strong>Belastningsprov<\/strong> k\u00f6ra och finjustera i sm\u00e5 steg.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx-optimierung-serverraum-5961.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NGINX-arkitektur: Att f\u00f6rst\u00e5 master- och worker-instanser<\/h2>\n<p>Jag skiljer uppgifterna fr\u00e5n <strong>M\u00e4stare<\/strong> och arbetare: Mastern laddar konfigurationer, \u00f6ppnar socklar och startar processer, medan arbetarna bearbetar f\u00f6rfr\u00e5gningar i h\u00e4ndelseslingan. Varje arbetare k\u00f6rs sj\u00e4lvst\u00e4ndigt, reagerar p\u00e5 h\u00e4ndelser och kan hantera tusentals anslutningar utan att orsaka blockeringar. Denna modell fungerar utm\u00e4rkt n\u00e4r jag utnyttjar CPU-k\u00e4rnorna p\u00e5 r\u00e4tt s\u00e4tt och utnyttjar h\u00e4ndelseslingan optimalt via epoll. Jag \u00e4r medveten om att varje ytterligare proxy-hopp tar upp anslutningsresurser, vilket \u00e5terspeglas i gr\u00e4nserna. Den som f\u00f6rst\u00e5r rollerna kan fatta medvetna beslut om <strong>Resurser<\/strong> och f\u00f6rebygger flaskhalsar i ett tidigt skede.<\/p>\n\n<h2>Att koppla samman de tre nyckelriktlinjerna p\u00e5 r\u00e4tt s\u00e4tt<\/h2>\n<p>Jag \u00f6verv\u00e4ger <strong>arbetare_processer<\/strong>, worker_connections och worker_rlimit_nofile ska aldrig justeras var f\u00f6r sig, utan som en helhet. Det totala antalet m\u00f6jliga anslutningar ber\u00e4knas genom att multiplicera antalet arbetare med antalet anslutningar per arbetare; utifr\u00e5n detta fastst\u00e4ller jag gr\u00e4nsv\u00e4rden f\u00f6r filbeskrivare. Om dessa inst\u00e4llningar inte st\u00e4mmer \u00f6verens st\u00f6ter jag p\u00e5 felet \u201etoo many open files\u201c eller drabbas av h\u00e5rda timeouts. Vid h\u00f6g belastning beh\u00f6ver jag en v\u00e4lavst\u00e4md kedja: tillr\u00e4ckligt m\u00e5nga processer, gener\u00f6sa anslutningar, ordentligt h\u00f6jt rlimit_nofile och l\u00e4mpliga operativsystemparametrar. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rhindrar jag att ett f\u00f6r litet <strong>Begr\u00e4nsa<\/strong> hela kapaciteten har minskats.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx_worker_meeting_3021.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>worker_processes: V\u00e4lj antal medvetet<\/h2>\n<p>Jag st\u00e4ller in <strong>arbetare_processer<\/strong> vanligtvis inst\u00e4lld p\u00e5 \u201eauto\u201c, s\u00e5 att NGINX kan identifiera antalet logiska CPU-k\u00e4rnor och utnyttja varje k\u00e4rna. En worker per k\u00e4rna undviker on\u00f6diga kontextbyten och f\u00f6rdelar belastningen j\u00e4mnt, vilket g\u00f6r att svarstiden f\u00f6rblir f\u00f6ruts\u00e4gbar. P\u00e5 maskiner med v\u00e4ldigt m\u00e5nga k\u00e4rnor testar jag medvetet \u00e4ven l\u00e4gre antal arbetare f\u00f6r att j\u00e4mf\u00f6ra cachetr\u00e4ffar och k\u00e4rnutnyttjande. Om m\u00e4tv\u00e4rdena visar att k\u00e4rnorna \u00e4r \u00f6verbelastade eller att TLB-missar \u00f6kar, justerar jag antalet arbetare stegvis. F\u00f6rst m\u00e4ta, sedan \u00e4ndra \u2013 s\u00e5 s\u00e4kerst\u00e4ller jag tillf\u00f6rlitliga <strong>Resultat<\/strong>.<\/p>\n\n<h2>worker_connections: \u00d6ka antalet anslutningar p\u00e5 ett planerat s\u00e4tt<\/h2>\n<p>Jag v\u00e4ljer <strong>arbetare_anslutningar<\/strong> beroende p\u00e5 m\u00e5ltrafik och protokollmix, ofta med utg\u00e5ngspunkt fr\u00e5n 2048 eller 4096. F\u00f6r API:er med h\u00f6g trafik \u00f6verv\u00e4ger jag 8192, f\u00f6rutsatt att operativsystemets begr\u00e4nsningar och RAM-minnet till\u00e5ter det. Varje \u00f6kning testar jag med belastningstester, eftersom \u00f6ppna anslutningar binder minne och p\u00e5verkar uppstr\u00f6msbeteendet. Om SSL-handskakningar eller stora uppladdningar dominerar utg\u00e5r jag hellre fr\u00e5n CPU- och I\/O-profiler, inte bara fr\u00e5n rena anslutningssiffror. P\u00e5 s\u00e5 s\u00e4tt s\u00e4kerst\u00e4ller jag att den per arbetare definierade <strong>Kapacitet<\/strong> f\u00f6rblir praktiskt anv\u00e4ndbar.<\/p>\n\n<h2>Synkronisera worker_rlimit_nofile och operativsystemets gr\u00e4nsv\u00e4rden<\/h2>\n<p>Jag ser till att <strong>rlimit_nofile<\/strong> t\u00e4cker \u00e5tminstone den ber\u00e4knade totalkapaciteten och \u00e4r ofta konfigurerad med en reserv. F\u00f6r reverse-proxy-scenarier r\u00e4knar jag in en andra deskriptor till uppstr\u00f6ms per klientanslutning. D\u00e4rf\u00f6r st\u00e4ller jag g\u00e4rna in rlimit_nofile till dubbelt s\u00e5 h\u00f6gt som det f\u00f6rv\u00e4ntade antalet samtidiga anslutningar. Jag h\u00f6jer k\u00e4rn- och anv\u00e4ndargr\u00e4nserna (ulimit -n, fs.file-max) s\u00e5 att NGINX faktiskt kan utnyttja v\u00e4rdena. Om det dyker upp meddelanden om \u00f6ppna filer i felloggen h\u00f6jer jag gr\u00e4nserna snabbt och \u00f6vervakar <strong>F\u00f6rdr\u00f6jning<\/strong> under belastning igen.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx-performance-optimization-5123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Evenemangsblock: effektiv anv\u00e4ndning av epoll och multi_accept<\/h2>\n<p>Jag aktiverar i h\u00e4ndelseblocket <strong>epoll<\/strong> och st\u00e4ller in multi_accept p\u00e5 \u201eon\u201c, s\u00e5 att arbetare tar emot v\u00e4ntande anslutningar i en enda omg\u00e5ng. Epoll minskar overhead vid m\u00e5nga samtidiga socklar och passar v\u00e4l ihop med NGINX:s icke-blockerande design. Dessa inst\u00e4llningar l\u00f6nar sig vid trafiktoppar, eftersom de p\u00e5skyndar mottagningsfasen och g\u00f6r att jag snabbare kommer vidare till sj\u00e4lva bearbetningen. F\u00f6r Linux \u00e4r detta min standardinst\u00e4llning, som jag endast \u00e4ndrar i s\u00e4llsynta specialfall. Den som vill f\u00f6rdjupa sig ytterligare kan j\u00e4mf\u00f6ra event-loop-modellen med <a href=\"https:\/\/webhosting.de\/sv\/tradpool-webbserver-apache-nginx-litespeed-optimering-konfiguration\/\">Tr\u00e5dpool kontra h\u00e4ndelseslinga<\/a> och drar d\u00e4rav slutsatsen att <strong>slutsatser<\/strong> f\u00f6r sin egen omgivning.<\/p>\n\n<h2>CPU-affinitet: Binda arbetare till k\u00e4rnor<\/h2>\n<p>Jag st\u00e4ller in <strong>worker_cpu_affinity<\/strong> anv\u00e4nder jag detta specifikt n\u00e4r arbetsbelastningarna \u00e4r konstanta och CPU-bundna. Jag f\u00f6rdelar tilldelningsschemat via bitmasker f\u00f6r att undvika kontextbyten och fr\u00e4mja cache-lokalitet. Med fyra k\u00e4rnor tilldelar jag maskerna s\u00e5 att varje arbetare f\u00e5r en egen k\u00e4rna. D\u00e4refter kontrollerar jag cache-miss-frekvenser, medianlatenser och 99-percentiler f\u00f6r att tydligt se effekten. Mer detaljerad information om affinitet och NUMA hittar du sammanfattat p\u00e5 <a href=\"https:\/\/webhosting.de\/sv\/server-process-affinitet-numa-medvetenhet-hosting-ressourcentuning\/\">CPU-affinitet i praktiken<\/a>, vilket vid finjusteringen av <strong>Arbetare<\/strong>-Layouts \u00e4r till hj\u00e4lp.<\/p>\n\n<h2>Kapacitetsplanering: Reservkapacitet och belastningstester<\/h2>\n<p>N\u00e4r det g\u00e4ller kopplingar planerar jag en <strong>Buffert<\/strong> ett v\u00e4rde som ligger betydligt \u00f6ver de observerade topparna, s\u00e5 att kortvariga toppar inte direkt \u00f6verskrider gr\u00e4nsv\u00e4rdena. Om jag dubblar toppbelastningen som utg\u00e5ngspunkt f\u00e5r jag i m\u00e5nga scenarier ett gediget utrymme. Vid kraftigt fluktuerande trafik ut\u00f6kar jag buffertmarginalen ytterligare tills 99-percentilen ser stabil ut. D\u00e4refter kontrollerar jag flaskhalsar med verktyg som wrk eller k6, \u00f6vervakar felprocenten och tittar p\u00e5 \u00f6ppna anslutningar i statusen. F\u00f6rst n\u00e4r m\u00e4tv\u00e4rdena \u00e4r konsekventa h\u00f6jer eller s\u00e4nker jag specifikt enskilda <strong>V\u00e4rden<\/strong>.<\/p>\n\n<h2>Konfiguration och r\u00e4kneexempel<\/h2>\n<p>Jag ber\u00e4knar anslutningskapaciteten genom att multiplicera antalet arbetare med antalet anslutningar per arbetare och s\u00e4tter sedan gr\u00e4nserna n\u00e5got h\u00f6gre utifr\u00e5n detta. Med fyra CPU-k\u00e4rnor, inst\u00e4llningen \u201dauto\u201d och 4096 anslutningar per arbetare hamnar jag enligt ber\u00e4kningarna p\u00e5 16 384 samtidiga anslutningar. I proxyscenarier brukar jag s\u00e4tta rlimit_nofile till 32 768 eller h\u00f6gre, s\u00e5 att uppstr\u00f6ms-socklar ing\u00e5r. F\u00f6r sm\u00e5 maskiner med tv\u00e5 k\u00e4rnor r\u00e4cker det ofta med 2 048 anslutningar per arbetare, f\u00f6rutsatt att andelen uppladdningar och TLS-anslutningar f\u00f6rblir m\u00e5ttlig. F\u00f6ljande tabell hj\u00e4lper till att klassificera <strong>Startv\u00e4rden<\/strong>:<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>CPU-k\u00e4rnor<\/th>\n      <th>arbetare_processer<\/th>\n      <th>worker_connections (Start)<\/th>\n      <th>Min. rlimit_nofile (riktv\u00e4rde)<\/th>\n      <th>Ledtr\u00e5d<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>2<\/td>\n      <td>bil (\u22482)<\/td>\n      <td>2048<\/td>\n      <td>\u2265 4096<\/td>\n      <td><strong>Reserv<\/strong> Planera f\u00f6r TLS\/proxy<\/td>\n    <\/tr>\n    <tr>\n      <td>4<\/td>\n      <td>bil (\u22484)<\/td>\n      <td>4096<\/td>\n      <td>\u2265 16 384<\/td>\n      <td>Vid proxy \u00e4r det ofta faktor 2 vid FD:er<\/td>\n    <\/tr>\n    <tr>\n      <td>8<\/td>\n      <td>bil (\u22488)<\/td>\n      <td>4096-8192<\/td>\n      <td>\u2265 32 768<\/td>\n      <td><strong>Belastningstest<\/strong> beslutar om h\u00f6jning<\/td>\n    <\/tr>\n    <tr>\n      <td>16+<\/td>\n      <td>bil, eventuellt f\u00e4rre<\/td>\n      <td>8192+<\/td>\n      <td>\u2265 65535<\/td>\n      <td>Testa med k\u00e4nsla och \u00e5terh\u00e5llsamhet<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx_performance_opt_4732.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NGINX-arbetare och uppstr\u00f6ms: Att viktiga scenarier p\u00e5 r\u00e4tt s\u00e4tt<\/h2>\n<p>Jag skiljer mellan statisk leverans, reverse proxy-drift och API-gateway-belastning, eftersom de <strong>Arbetare<\/strong>-Konfigurationen st\u00e4ller olika krav. Statiskt inneh\u00e5ll tar mindre resurser i anspr\u00e5k, medan TLS, komprimering och uppstr\u00f6msanslutningar belastar CPU och filbeskrivare (FD) mer. Ju st\u00f6rre SSL-nycklarna \u00e4r och ju fler handskakningar som kr\u00e4vs, desto st\u00f6rre f\u00f6rdelar ger inst\u00e4llningen \u201een worker per k\u00e4rna\u201c. Stora uppladdningar f\u00f6rskjuter profilen mot I\/O, vilket g\u00f6r att jag snarare fokuserar p\u00e5 rlimit_nofile och n\u00e4tverksbuffertar. Vid m\u00e4rkbara v\u00e4ntetider f\u00f6r mottagning eller svar fr\u00e5n backend hj\u00e4lper \u00f6versikten mig att <a href=\"https:\/\/webhosting.de\/sv\/webbserver-koe-latens-begaeran-hantering-serverkoe\/\">K\u00f6er och latens<\/a>, f\u00f6r att undvika flaskhalsar <strong>riktade<\/strong> l\u00f6sa.<\/p>\n\n<h2>Arbetsfl\u00f6de i praktiken: Steg f\u00f6r steg mot en snabbare server<\/h2>\n<p>Jag b\u00f6rjar med att g\u00f6ra en kartl\u00e4ggning av alla relevanta <strong>V\u00e4rden<\/strong> I nginx.conf kontrollerar jag CPU-k\u00e4rnor, ulimit och k\u00e4rnparametrar. D\u00e4refter st\u00e4ller jag in worker_processes p\u00e5 auto, anger worker_connections till exempelvis 4096 och h\u00f6jer rlimit_nofile gener\u00f6st. I Events-blocket aktiverar jag epoll och multi_accept och kontrollerar loggarna med en omladdning. D\u00e4refter f\u00f6ljer belastningstester under reproducerbara f\u00f6rh\u00e5llanden, d\u00e4r jag observerar svarstider, felfrekvenser och \u00f6ppna anslutningar. I finjusteringen \u00e4ndrar jag alltid bara en variabel, dokumenterar varje steg och kontrollerar effekterna i <strong>M\u00e4tetal<\/strong>.<\/p>\n\n<h2>Webbhotellsmilj\u00f6: resurser, k\u00e4rna, n\u00e4tverk<\/h2>\n<p>Jag ser till att det finns tillr\u00e4ckligt med <strong>CPU<\/strong>-K\u00e4rnor, tillr\u00e4ckligt med RAM, snabba SSD-enheter eller NVMe och en aktuell Linux-k\u00e4rna. Endast p\u00e5 detta s\u00e4tt fungerar epoll, moderna TCP-stackar och anv\u00e4ndbara avlastningsfunktioner p\u00e5 ett tillf\u00f6rlitligt s\u00e4tt. Jag anpassar n\u00e4tverksparametrar som somaxconn och tcp_max_syn_backlog efter det \u00f6nskade antalet anslutningar f\u00f6r att h\u00e5lla mottagningsk\u00f6erna korta. En leverant\u00f6r med stabil I\/O-prestanda och fritt tillg\u00e4nglig systemkonfiguration l\u00f6nar sig klart i detta sammanhang. J\u00e4mf\u00f6relser visar att tj\u00e4nster med konstanta <strong>Resurser<\/strong> \u00d6ka NGINX:s flexibilitet avsev\u00e4rt.<\/p>\n\n<h2>Keepalive-strategi: Klient- och uppstr\u00f6msanslutningar<\/h2>\n<p>Jag anv\u00e4nder Keepalive medvetet som ett verktyg f\u00f6r att p\u00e5verka kapacitet och latens. P\u00e5 klientsidan anv\u00e4nder jag <strong>keepalive_timeout<\/strong> inte f\u00f6r h\u00f6gt, s\u00e5 att inaktiva socklar inte i on\u00f6dan <em>arbetare_anslutningar<\/em> blockera. V\u00e4rden mellan 10\u201330 s ger mig ofta en bra avv\u00e4gning mellan \u00e5teranv\u00e4ndning och resursbindning. Med <strong>keepalive_requests<\/strong> begr\u00e4nsar jag antalet f\u00f6rfr\u00e5gningar per anslutning f\u00f6r att stoppa l\u00e5ngvariga anslutningar och undvika belastning p\u00e5 minnet. P\u00e5 uppstr\u00f6msidan (reverse-proxy) uppr\u00e4tth\u00e5ller jag best\u00e4ndiga anslutningar med <strong>keepalive<\/strong> i uppstr\u00f6msblocket, vilket inneb\u00e4r att handskakningar och TCP-uppkoppling inte beh\u00f6vs. Jag skalar d\u00e5 antalet per backend konservativt i f\u00f6rh\u00e5llande till backend-kapaciteten (<em>max_conns<\/em>), annars skapar jag sj\u00e4lv k\u00f6er vid uppstr\u00f6msf\u00f6rs\u00e4ndningen. Viktigt: Varje keepalive-socket r\u00e4knas som en \u00f6ppen anslutning och kr\u00e4ver FD:er; det tar jag h\u00e4nsyn till i <em>rlimit_nofile<\/em> och min planering av utrymmet.<\/p>\n\n<h2>Listoptimering: reuseport, backlog och acceptansstrategi<\/h2>\n<p>Jag f\u00f6rdelar belastningen j\u00e4mnt genom att <strong>SO_REUSEPORT<\/strong> aktivera (listen \u2026 reuseport). Varje worker har d\u00e4rmed en egen accept-k\u00f6, vilket minskar \u201ethundering herds\u201c och f\u00f6rhindrar flaskhalsar. I kombination med <strong>multi_accept<\/strong> p\u00e5 s\u00e5 s\u00e4tt p\u00e5skyndar jag mottagningsfasen m\u00e4rkbart. Listan-<strong>eftersl\u00e4pning<\/strong> (listen \u2026 backlog=) och motsvarande inst\u00e4llningar i k\u00e4rnan (somaxconn, tcp_max_syn_backlog) st\u00e4ller jag in gener\u00f6st, s\u00e5 att toppar inte g\u00e5r f\u00f6rlorade vid socket-ing\u00e5ngen. Alternativet <strong>uppskjuten<\/strong> skjuter upp Accept tills data finns tillg\u00e4ngliga \u2013 vid m\u00e5nga kortlivade f\u00f6rfr\u00e5gningar kan det vara till hj\u00e4lp, annars j\u00e4mf\u00f6r jag i tester. Om jag <strong>accept_mutex<\/strong> Vad jag beh\u00f6ver avg\u00f6r jag utifr\u00e5n j\u00e4mf\u00f6relsen: Med reuseport \u00e4r det oftast on\u00f6digt; utan reuseport kan det f\u00f6rb\u00e4ttra r\u00e4ttvisan, men kr\u00e4ver samordning. H\u00e4r fattar jag beslut utifr\u00e5n data, aldrig p\u00e5 k\u00e4nsla.<\/p>\n\n<h2>Stabil inst\u00e4llning av timeouts och k\u00f6er<\/h2>\n<p>Jag st\u00e4ller in <strong>Tidsfrister<\/strong> s\u00e5 att l\u00e5ngsamma klienter inte \u00f6verbelastar arbetarna: <em>client_header_timeout<\/em> och <em>klient_kropp_timeout<\/em> Jag h\u00e5ller det tillr\u00e4ckligt kort f\u00f6r att undvika avbrott, men tillr\u00e4ckligt omfattande f\u00f6r verkliga anv\u00e4ndare. <em>send_timeout<\/em> skyddar mot blockerade svar till klienten. I proxysammanhanget definierar jag <em>proxy_anslutning_timeout<\/em>, <em>proxy_read_timeout<\/em> och <em>proxy_send_timeout<\/em> strikt, s\u00e5 att h\u00e4ngande backend-processer inte lamsl\u00e5r frontenden. F\u00f6r backend-processer med begr\u00e4nsad parallellitet anv\u00e4nder jag <strong>k\u00f6<\/strong> i uppstr\u00f6msblocket med timeout f\u00f6r att d\u00e4mpa toppar och p\u00e5 ett kontrollerat s\u00e4tt signalera 503, ist\u00e4llet f\u00f6r att binda alla arbetare till v\u00e4ntande uppstr\u00f6ms-socklar. Dessutom stabiliserar jag med <strong>limit_req<\/strong> (Burst\/Delay) och <strong>limit_conn<\/strong> k\u00e4nsliga v\u00e4gar, s\u00e5 att enskilda klienter eller botar inte tar upp oproportionerligt mycket resurser.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx_worker_performance_8392.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Buffring, sendfile och AIO: Att medvetet v\u00e4lja I\/O-metoder<\/h2>\n<p>Jag st\u00e4ller in <strong>sendfile<\/strong> f\u00f6r statiska filer och kombinera det med <em>tcp_nopush<\/em>\/<em>tcp_nodelay<\/em> beroende p\u00e5 arbetsbelastningen, f\u00f6r att effektivt sammanf\u00f6ra paket eller minska f\u00f6rdr\u00f6jningarna vid interaktiva uppgifter. F\u00f6r stora filer anv\u00e4nder jag <strong>direktiv<\/strong> fr\u00e5n och med ett visst tr\u00f6skelv\u00e4rde, s\u00e5 att cachef\u00f6rorening undviks och sidcachen inte tr\u00e4ngs undan. I proxyl\u00e4ge best\u00e4mmer jag om <strong>proxy_buffering<\/strong> hj\u00e4lper (snabb \u00f6verf\u00f6ring till klienten, avkopplad uppstr\u00f6msavl\u00e4sning) eller om jag vid str\u00f6mmingsbelastningar hellre b\u00f6r <em>proxy_request_buffering<\/em> minska f\u00f6r att s\u00e4tta ig\u00e5ng uppladdningarna i god tid. Storlekarna p\u00e5 <em>proxy_buffers<\/em>, <em>proxy_buffer_size<\/em> och <em>stora_klienthuvudbuffertar<\/em> Jag styr detta medvetet f\u00f6r att minnesanv\u00e4ndningen per anslutning inte ska skjuta i h\u00f6jden. F\u00f6r att minska belastningen p\u00e5 processorn vid fil\u00e5tkomst \u00f6verv\u00e4ger jag <strong>aio<\/strong> (native eller tr\u00e5dar), men testa noggrant, eftersom event-loopens och I\/O:s egenskaper p\u00e5verkar varandra.<\/p>\n\n<h2>HTTP\/2\/HTTP\/3 och TLS: Effekter p\u00e5 arbetarkapaciteten<\/h2>\n<p>Jag tar h\u00e4nsyn till att <strong>HTTP\/2<\/strong> och <strong>HTTP\/3<\/strong> \u00c4ndra anslutningsdynamiken: M\u00e5nga f\u00f6rfr\u00e5gningar k\u00f6rs som <em>Str\u00f6mmar<\/em> via ett f\u00e5tal TCP- respektive QUIC-anslutningar. Detta minskar antalet anslutningar, men \u00f6kar samtidigt CPU- och minnesbehovet per anslutning (multiplexering, header-komprimering, TLS\/QUIC). Min <em>arbetare_anslutningar<\/em> D\u00e4rf\u00f6r tolkar jag det inte blint som \u201elika m\u00e5nga f\u00f6rfr\u00e5gningar\u201c. Jag observerar <em>parallella str\u00f6mmar<\/em> per anslutning och passning <em>keepalive_timeout<\/em> och eventuellt. <em>http2_max_concurrent_streams<\/em> . P\u00e5 TLS-sidan vinner jag p\u00e5 session-resumption (biljetter\/cache) och OCSP-stapling; p\u00e5 s\u00e5 s\u00e4tt slipper jag kostsamma handskakningar och h\u00e5ller latensen l\u00e5g. Nackdelen: L\u00e4ngre keepalives binder upp filer och RAM \u2013 d\u00e4rf\u00f6r planerar jag <em>rlimit_nofile<\/em> och minneskvoter med realistiska reserver. F\u00f6r CPU-kr\u00e4vande krypteringsalgoritmer l\u00f6nar det sig att testa med affinitet och modern kryptografisk acceleration.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx-optimaler-setup-9182.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>\u00d6vervakbarhet: Status, loggar och m\u00e4tv\u00e4rden<\/h2>\n<p>Jag skapar \u00f6ppenhet med en smidig <strong>Status<\/strong>-Endpoint (t.ex. stub_status) f\u00f6r att se aktiva anslutningar, l\u00e4sning\/skrivning\/v\u00e4ntel\u00e4ge och godk\u00e4nda f\u00f6rfr\u00e5gningar. I loggarna f\u00f6rs\u00f6ker jag minimera bruset: En kompakt <em>log_format<\/em> med tid, status, uppstr\u00f6ms-tider och byte r\u00e4cker f\u00f6r de flesta analyser. Vid mycket h\u00f6g QPS inaktiverar jag \u00e5tkomstloggen selektivt (platsbaserat) eller buffrar loggarna asynkront s\u00e5 att I\/O inte bromsar. Fel-loggen st\u00e4ller jag in p\u00e5 <em>varna<\/em> eller . <em>fel<\/em> och byt endast tillf\u00e4lligt till <em>fels\u00f6kning<\/em>. Jag korrelerar l\u00f6pande latenser (median\/95:e\/99:e percentilen), \u00f6ppna anslutningar, felprocent i backend och CPU-belastning per arbetare \u2013 utifr\u00e5n detta fastst\u00e4ller jag justeringar av de tre nyckeldirektiven och uppt\u00e4cker m\u00e4ttnadseffekter i ett tidigt skede.<\/p>\n\n<h2>Containrar och virtuella milj\u00f6er: \u00d6verf\u00f6ra gr\u00e4nser p\u00e5 ett smidigt s\u00e4tt<\/h2>\n<p>Jag kontrollerar i containrarna de <strong>cgroup<\/strong>-Ange gr\u00e4nsv\u00e4rden f\u00f6r CPU, RAM och PID:er och anpassa dem efter NGINX-inst\u00e4llningarna. <em>ulimit -n<\/em> m\u00e5ste vara tillr\u00e4ckligt h\u00f6gt inom containern, annars blir mina justeringar av rlimit_nofile verkningsl\u00f6sa. Vid CPU-kvoter (t.ex. 2 vCPU:er) st\u00e4ller jag in <em>arbetare_processer<\/em> i enlighet med detta, s\u00e5 att schemal\u00e4ggningen inte skapar on\u00f6dig tr\u00e4ngsel. N\u00e4r jag \u00e4r n\u00e4ra n\u00e4tverket drar jag nytta av l\u00e4gre overhead-latens i \u201ehost\u201c-n\u00e4tverksl\u00e4gen, medan \u00f6verlagringar inneb\u00e4r ytterligare hopp. P\u00e5 Multi-NUMA-v\u00e4rdar \u00e4r jag noga med affinitet och minnesocklar s\u00e5 att arbetare inte arbetar tv\u00e4rs \u00f6ver noder. Detsamma g\u00e4ller f\u00f6r IRQ- och RPS\/XPS-affinitet: om v\u00e4garna fr\u00e5n n\u00e4tverkskortet via IRQ till arbetark\u00e4rnan st\u00e4mmer, minskar latensspikarna m\u00e4rkbart.<\/p>\n\n<h2>Anslutningens livscykel: kortlivade portar, TIME_WAIT och reserver<\/h2>\n<p>Jag planerar tillr\u00e4ckligt <strong>tillf\u00e4lliga portar<\/strong> (ip_local_port_range) n\u00e4r NGINX fungerar som aktiv klient gentemot uppstr\u00f6ms-servrarna. Vid mycket h\u00f6g anslutningsgenomstr\u00f6mning undviker jag \u00f6verdriven portfluktuation med uppstr\u00f6ms-keepalive, vilket minskar TIME_WAIT-k\u00f6erna. Jag anv\u00e4nder endast med f\u00f6rsiktighet kernel-toggles f\u00f6r \u201eReuse\u201c; moderna stackar optimerar redan mycket internt. Det \u00e4r stabilare att styra anslutningarnas livsl\u00e4ngd genom l\u00e4mpliga Keepalive- och timeout-v\u00e4rden och <em>\u00e5teranv\u00e4nda<\/em> f\u00f6r att s\u00e4kerst\u00e4lla en r\u00e4ttvis f\u00f6rdelning. Vid kapacitetsber\u00e4kningen tar jag alltid h\u00e4nsyn till uppstr\u00f6msdelen ut\u00f6ver klienterna \u2013 ofta \u00e4r det FD:erna d\u00e4r som utg\u00f6r den egentliga begr\u00e4nsande faktorn, inte frontdoor.<\/p>\n\n<h2>Smidiga omstartar och drifts\u00e4ttningar utan avbrott<\/h2>\n<p>Jag anv\u00e4nder master\/worker-modellen f\u00f6r <strong>smidiga omladdningar<\/strong>: Master-noden laddar in nya konfigurationer, gamla arbetare st\u00e4ngs av medan nya smidigt tar \u00f6ver. Med <em>timeout f\u00f6r avst\u00e4ngning av arbetare<\/em> l\u00e5ter jag f\u00f6rfr\u00e5gningarna avslutas ordentligt utan att blockera resurser. Jag kopplar ihop drifts\u00e4ttningar utan driftstopp p\u00e5 uppstr\u00f6ms med h\u00e4lsokontroller och <em>proxy_next_upstream<\/em>-Regler f\u00f6r att f\u00f6rhindra att enskilda felaktiga backend-komponenter \u00f6kar den globala latensen. N\u00e4r jag g\u00f6r konfigurations\u00e4ndringar \u00e4ndrar jag alltid bara en inst\u00e4llning i taget och verifierar effekterna i loggar och m\u00e4tv\u00e4rden \u2013 p\u00e5 s\u00e5 s\u00e4tt undviker jag misstag som beror p\u00e5 f\u00f6rvirring och s\u00e4kerst\u00e4ller att prestandan \u00e4r reproducerbar.<\/p>\n\n<h2>Kortfattad sammanfattning<\/h2>\n<p>Jag kopplar ihop <strong>arbetare_processer<\/strong> St\u00e4ll in antalet k\u00e4rnor (helst automatiskt), anpassa worker_connections efter toppbelastningen och h\u00f6j rlimit_nofile samt operativsystemets gr\u00e4nsv\u00e4rden gener\u00f6st. I Events-blocket anv\u00e4nder jag epoll och multi_accept, testar allt med reproducerbara belastningstester och justerar sedan i sm\u00e5 steg. F\u00f6r proxy-arbetsbelastningar r\u00e4knar jag in ytterligare deskriptorer och testar CPU-affinitet n\u00e4r arbetsbelastningarna \u00e4r konstanta. En korrekt konfigurerad stack med l\u00e4mplig k\u00e4rna, snabb I\/O och v\u00e4l valda n\u00e4tverksparametrar g\u00f6r hela skillnaden. S\u00e5 h\u00e4r g\u00f6r jag <strong>NGINX<\/strong> tillf\u00f6rlitligt inom det prestandaomr\u00e5de som kr\u00e4vande webbsidor och API:er beh\u00f6ver.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e4r dig hur du konfigurerar NGINX-arbetsprocesser p\u00e5 r\u00e4tt s\u00e4tt och avsev\u00e4rt f\u00f6rb\u00e4ttrar webbserverns prestanda genom m\u00e5linriktad NGINX-optimering.<\/p>","protected":false},"author":1,"featured_media":20707,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20714","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-webserver-plesk-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"151","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"NGINX Worker","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20707","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/20714","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/comments?post=20714"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/20714\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media\/20707"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media?parent=20714"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/categories?post=20714"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/tags?post=20714"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}