{"id":20890,"date":"2026-08-22T11:51:32","date_gmt":"2026-08-22T09:51:32","guid":{"rendered":"https:\/\/webhosting.de\/so-reuseport-linux-webserver-performance-optimierung-core\/"},"modified":"2026-08-22T11:51:32","modified_gmt":"2026-08-22T09:51:32","slug":"so-reuseport-linux-webserver-ydeevneoptimering-kerne","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/so-reuseport-linux-webserver-performance-optimierung-core\/","title":{"rendered":"SO_REUSEPORT under Linux: Bedre ydeevne til webservere"},"content":{"rendered":"<p>Jeg viser, hvordan SO_REUSEPORT g\u00f8r Linux-webservere hurtigere ved mange samtidige forbindelser og fjerner flaskehalse ved <strong>Accepter<\/strong> fjernet. Her satser jeg p\u00e5 klare, praktiske fremgangsm\u00e5der, s\u00e5 du p\u00e5 multicore-systemer kan f\u00e5 mere <strong>Str\u00f8m<\/strong> tager frem.<\/p>\n\n<h2>Centrale punkter<\/h2>\n<ul>\n  <li><strong>Accept-flaskehals<\/strong> undg\u00e5 og reducere ventetiden<\/li>\n  <li><strong>Multicore<\/strong> Effektiv udnyttelse gennem kernel-fordeling<\/li>\n  <li><strong>Tordnende komfur<\/strong> reducere markant<\/li>\n  <li><strong>Arkitektur<\/strong> forenkle uden Userland-Dispatcher<\/li>\n  <li><strong>Nginx<\/strong> og bruge andre servere direkte<\/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\/webserver-performance-3471.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvad SO_REUSEPORT l\u00f8ser rent teknisk<\/h2>\n\n<p>SO_REUSEPORT tildeler hver worker sin egen lytte-socket, s\u00e5 jeg kan bruge den klassiske <strong>flaskehals<\/strong> undg\u00e5 ved den centrale Accept. Tidligere var alt knyttet til \u00e9n socket, hvilket medf\u00f8rte konkurrence mellem tr\u00e5dene og l\u00e6ngere ventetider. I dag fordeler kernen nye forbindelser direkte p\u00e5 flere sockets, hvilket <strong>Forsinkelse<\/strong> m\u00e6rkbart. P\u00e5 den m\u00e5de undg\u00e5r jeg behovet for separate dispatcher-processer og sparer kontekstskift. Under h\u00f8j belastning forbliver responstiderne mere konstante, fordi ingen enkelt listener bremser systemet.<\/p>\n\n<h2>SO_REUSEPORT vs. SO_REUSEADDR \u2013 en kort sammenligning<\/h2>\n\n<p>SO_REUSEADDR hj\u00e6lper mig med at genstarte hurtigt, da jeg kan genbruge porte p\u00e5 trods af <strong>TIME_WAIT<\/strong> kan binde igen. SO_REUSEPORT g\u00f8r noget andet: flere lyttere samtidigt p\u00e5 den samme IP\/port-kombination. F\u00f8rst n\u00e5r jeg indstiller SO_REUSEPORT f\u00f8r bind()-kaldet, tillader kernen den parallelle <strong>Bind<\/strong>-Operation. R\u00e6kkef\u00f8lgen er stadig vigtig: Hvis en port er optaget uden denne indstilling, kan der ikke tilf\u00f8jes flere sockets. For parallelle workere er SO_REUSEPORT derfor en n\u00f8gleindstilling.<\/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\/optimierte_webserver_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Funktionsm\u00e5de i kernen: Reuseport-grupper og hash<\/h2>\n\n<p>Alle sockets med samme IP\/port-kombination og med SO_REUSEPORT aktiveret havner i en <strong>Gruppe<\/strong>. Kernel beregner for hver ny forbindelse en hash baseret p\u00e5 kilde- og m\u00e5lparametre. P\u00e5 dette grundlag tildeler den forbindelsen til en passende listener og fordeler dermed forbindelserne relativt retf\u00e6rdigt. Jeg drager fordel af bedre cache-lokalitet, fordi hver CPU oftere behandler \u201esine\u201c forbindelser. I s\u00e6rlige tilf\u00e6lde kan BPF <strong>Udv\u00e6lgelse<\/strong> tilpasse yderligere, f.eks. for at gennemf\u00f8re egne strategier.<\/p>\n\n<h2>Praksis: S\u00e5dan konfigureres Nginx korrekt<\/h2>\n\n<p>I Nginx aktiverer jeg \u00bbreuseport\u00ab med \u00bblisten\u00ab-direktivet og bruger flere <strong>Arbejder<\/strong>-processer. Et eksempel: Indstil `worker_processes` til antallet af kerner, og angiv \u201elisten 80 reuseport;\u201c i serverblokken. Herefter f\u00e5r hver worker sin egen listener, og kernen fordeler nye forbindelser automatisk. For n\u00e6rmere oplysninger om det optimale antal workers henviser jeg til <a href=\"https:\/\/webhosting.de\/da\/optimal-konfiguration-af-nginx-arbejdsprocesser-ydeevneforbedring\/\">Nginx-arbejderprocesser<\/a>. P\u00e5 den m\u00e5de opn\u00e5r jeg h\u00f8jere anmodningsfrekvenser og en j\u00e6vn udnyttelse af kernerne.<\/p>\n\n<h2>Effektiv udnyttelse af flerkernede CPU\u2019er<\/h2>\n\n<p>Med flere workere og SO_REUSEPORT bruger jeg <strong>Multicore<\/strong>-systemer mere ensartet. Jeg tildeler worker-processer til bestemte kerner via CPU-affinitet for at reducere cache-hopping. RSS\/RPS p\u00e5 netv\u00e6rkskortet hj\u00e6lper med at fordele indg\u00e5ende pakker p\u00e5 de rette k\u00f8er. P\u00e5 den m\u00e5de ender forbindelser oftere hos de \u201erigtige\u201c kerner, hvilket <strong>Gennemstr\u00f8mning<\/strong>-h\u00e6ver hastigheden. Effekten er is\u00e6r m\u00e6rkbar ved mange korte forbindelser og TLS-h\u00e5ndtryk.<\/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\/linux-server-performance-boost-2341.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Overv\u00e5gning, rullende genstarter og faldgruber<\/h2>\n\n<p>Jeg planl\u00e6gger rullende genstarter med forsigtighed, da lukning af en lyttende socket kan f\u00f8re til tab af <strong>Eftersl\u00e6b<\/strong>-poster. Inden jeg afslutter en worker, s\u00f8rger jeg for, at dens k\u00f8er er tomme, og f\u00f8rst derefter tager jeg den ud af drift. Til logfiler v\u00e6lger jeg separate filer for hver worker, s\u00e5 jeg senere kan f\u00f8lge med i fordelingen. Overv\u00e5gningsv\u00e6rkt\u00f8jer skal tage h\u00f8jde for flere processer, ellers kan m\u00e5lingerne v\u00e6re vildledende. N\u00e5r det g\u00e6lder IP-bindinger, l\u00e6gger jeg v\u00e6gt p\u00e5 konsistens, da 0.0.0.0 og specifikke IP-adresser ellers <strong>Konflikter<\/strong> kan generere.<\/p>\n\n<h2>SO_REUSEPORT ud over HTTP<\/h2>\n\n<p>Dette princip hj\u00e6lper mig ogs\u00e5 med <strong>UDP<\/strong>-tjenester som DNS, streaming eller spilservere. Mange nye pakker pr. sekund fordeles s\u00e5ledes p\u00e5 flere lyttere, uden at jeg har brug for en userland-loadbalancer. TCP-proxyer, gateways og IoT-platforme drager ogs\u00e5 fordel heraf. Det er vigtigt at have det rigtige antal arbejdsprocesser, s\u00e5 hardware og software arbejder i takt. Jeg kombinerer ops\u00e6tningen med klare <strong>Gr\u00e6nser<\/strong> for filbeskrivere og korrekte timeout-v\u00e6rdier.<\/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\/linux_nacht_webserver_7834.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Optimering af netv\u00e6rksstakken: IRQ, offloads, buffere<\/h2>\n\n<p>Jeg tjekker NIC\u2019ens IRQ-fordeling, s\u00e5 k\u00f8erne bliver tildelt de rette <strong>CPU<\/strong>-kerner. Hvor det er hensigtsm\u00e6ssigt, bruger jeg GRO\/LRO og offloads, men tester altid latenstiden. Jeg indstiller socket-bufferen bevidst, da for sm\u00e5 v\u00e6rdier bremser ved spidsbelastninger, og for store v\u00e6rdier spilder hukommelse; mere herom under <a href=\"https:\/\/webhosting.de\/da\/server-socket-buffere-hosting-tuning-bufferopti\/\">Socket-buffer<\/a>. Jeg sammenligner ogs\u00e5 sysctl-parametre som somaxconn og net.core.somaxconn med arbejdsbelastningsprofilen. Jeg m\u00e5ler effekten af hver \u00e6ndring for sig for at f\u00e5 et reelt <strong>Gevinster<\/strong> at se.<\/p>\n\n<h2>Sammenligning af almindelige webserver-ops\u00e6tninger<\/h2>\n\n<p>Den f\u00f8lgende tabel viser typiske egenskaber ved forskellige lyttermodeller og hj\u00e6lper mig med at <strong>Valgmuligheder<\/strong> af designet. Jeg fokuserer p\u00e5 acceptstien, latenstiden under belastning, skaleringsegenskaberne, arkitekturomkostningerne og CPU-udnyttelsen. P\u00e5 den m\u00e5de kan jeg hurtigt se, hvilken ops\u00e6tning der passer til min trafikprofil. Jeg adskiller teori fra praksis ved efterf\u00f8lgende at kontrollere de faktiske m\u00e5linger. Den <strong>Matrix<\/strong> fungerer som udgangspunkt for m\u00e5lrettede tests.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Ops\u00e6tning<\/th>\n      <th>Accept-sti<\/th>\n      <th>Latenstid under belastning<\/th>\n      <th>Skalering<\/th>\n      <th>Arkitektomkostninger<\/th>\n      <th>Udnyttelse af CPU<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>En lytter uden SO_REUSEPORT<\/td>\n      <td>En <strong>Sokkel<\/strong><\/td>\n      <td>stiger tidligt<\/td>\n      <td>begr\u00e6nset<\/td>\n      <td>lav<\/td>\n      <td>ulige<\/td>\n    <\/tr>\n    <tr>\n      <td>Flere arbejdere med SO_REUSEPORT<\/td>\n      <td>Kernel-<strong>Distribution<\/strong><\/td>\n      <td>mere konstant<\/td>\n      <td>h\u00f8j<\/td>\n      <td>lav<\/td>\n      <td>mere j\u00e6vn<\/td>\n    <\/tr>\n    <tr>\n      <td>Userland-dispatcher<\/td>\n      <td>central modtagelse<\/td>\n      <td>Medium<\/td>\n      <td>Medium<\/td>\n      <td>h\u00f8j<\/td>\n      <td>skiftende<\/td>\n    <\/tr>\n    <tr>\n      <td>SO_REUSEPORT + BPF-logik<\/td>\n      <td>tilpasset udv\u00e6lgelse<\/td>\n      <td>meget stabil<\/td>\n      <td>Meget h\u00f8j<\/td>\n      <td>Medium<\/td>\n      <td>meget j\u00e6vnt<\/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\/entwicklerschreibtisch0391.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Planl\u00e6g benchmarks grundigt<\/h2>\n\n<p>Jeg tester med og uden SO_REUSEPORT for at f\u00e5 reelle <strong>Forskelle<\/strong> at se. Relevante n\u00f8gletal er antal anmodninger pr. sekund, p95\/p99-latenser og CPU-udnyttelse pr. kerne. Jeg varierer antallet af arbejdsprocesser og unders\u00f8ger det optimale punkt mellem kontekstskift og udnyttelse. Jeg v\u00e6lger testdata, der afspejler virkeligheden, herunder TLS, Keep-Alive samt statisk og dynamisk indhold. Jeg registrerer resultaterne p\u00e5 en reproducerbar m\u00e5de, s\u00e5 jeg senere <strong>\u00c6ndringer<\/strong> kan sammenlignes med.<\/p>\n\n<h2>Apache: Effektiv brug af Event-MPM<\/h2>\n\n<p>Ogs\u00e5 Apache drager fordel af det, hvis jeg adskiller Accept-stien og <strong>Begivenhed<\/strong>-MPM korrekt. Valget mellem Event-MPM og Worker-MPM afh\u00e6nger af forbindelsesprofilen og ressourcerne. Jeg tager h\u00f8jde for keep-alive, tr\u00e5dpuljer og begr\u00e6nsninger for klienter. Denne oversigt hj\u00e6lper mig med at danne mig et overblik: <a href=\"https:\/\/webhosting.de\/da\/apache-event-mpm-vs-worker-mpm-finjustering-og-optimering-af-webserveren\/\">Event-MPM kontra Worker-MPM<\/a>. I forbindelse med SO_REUSEPORT arbejder jeg m\u00e5lrettet p\u00e5 at opn\u00e5 en j\u00e6vn <strong>Belastning<\/strong> pr. proces.<\/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\/server-performance-linux-4852.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Begr\u00e6nsninger og finesser ved fordelingen<\/h2>\n<p>SO_REUSEPORT fordeler indg\u00e5ende forbindelser relativt retf\u00e6rdigt ved hj\u00e6lp af hash, men ikke helt j\u00e6vnt. Spidsbelastninger kan kortvarigt ramme enkelte workere h\u00e5rdere, hvis kilde-\/m\u00e5lparametre medf\u00f8rer en uheldig fordeling. Jeg overv\u00e5ger derfor ved hj\u00e6lp af worker-metrikker (accepts, aktive forbindelser, CPU) og justerer antallet af workere, affiniteterne og RSS-k\u00f8erne. Keep-Alive-forbindelser forbliver hos den oprindelige listener, hvilket giver den \u00f8nskede cache-lokalitet, men ogs\u00e5 kan f\u00f8re til \u201esticky\u201c belastningsm\u00f8nstre. Ved meget heterogene anmodninger (blandet CPU-\/I\/O-belastning) planl\u00e6gger jeg buffere for at afb\u00f8de korte spidsbelastninger.<\/p>\n\n<h2>Accept-stien i detaljer: Backlog, somaxconn og SYN-k\u00f8er<\/h2>\n<p>Jeg skelner mellem listen-k\u00f8en (SYN-backlog) og accept-k\u00f8en. Parametre som net.ipv4.tcp_max_syn_backlog, tcp_syncookies og net.core.somaxconn p\u00e5virker, hvor mange forbindelsesfors\u00f8g og fuldt etablerede sockets der opbevares. Backloggen g\u00e6lder separat for hver listener-socket \u2013 med SO_REUSEPORT multipliceres den teoretiske bufferkapacitet p\u00e5 tv\u00e6rs af alle arbejdsprocesser. I praksis er det dog netv\u00e6rkskortet og CPU-belastningen, der s\u00e6tter gr\u00e6nserne. Jeg holder backlogs konsistente og m\u00e5ler drop- og retransmit-rater for tidligt at opdage flaskehalse.<\/p>\n\n<h2>Nginx-detaljer: accept_mutex, nedlukning af arbejdsprocesser og TLS<\/h2>\n<p>S\u00e5 snart jeg bruger reuseport, deaktiverer jeg accept_mutex i Nginx, da kernen s\u00f8rger for en retf\u00e6rdig fordeling. Ved en rullende genstart v\u00e6lger jeg \u201egraceful\u201c og afventer Keep-Alive-forbindelser, s\u00e5 ingen lange overf\u00f8rsler afbrydes. P\u00e5 TLS-siden s\u00f8rger jeg for f\u00e6lles ticket-n\u00f8gler mellem workere\/instanser, s\u00e5 genoptagelse og sessions-ID'er fungerer uafh\u00e6ngigt af den tildelte listener. Jeg kontrollerer, at workerne ikke bliver for store (cache- og hukommelsesforbrug), for at undg\u00e5 kolde cacher ved processkift.<\/p>\n\n<h2>Aktivering af systemd-sockets, containere og orkestrering<\/h2>\n<p>Hvis systemd \u00e5bner sockets p\u00e5 forh\u00e5nd, skal det indstille SO_REUSEPORT, ellers blokeres parallelle bind-operationer. I container-milj\u00f8er s\u00f8rger jeg for, at det \u00f8nskede antal workere pr. pod\/container rent faktisk oprettes, og at cgroup-CPU-tildelingen passer til affinitetsstrategien. I orkestratorer planl\u00e6gger jeg strategien for rullende opdateringer s\u00e5ledes, at Reuseport-gruppen forbliver stabil under deployment og ikke blokerer nogen port eksklusivt. Healthchecks b\u00f8r ikke skabe un\u00f8dvendig st\u00f8j pr. worker og forvride fordelingen.<\/p>\n\n<h2>NUMA-bevidsthed og hukommelseslokalitet<\/h2>\n<p>P\u00e5 NUMA-systemer knytter jeg arbejdsprocesser til kerner i samme NUMA-node og sikrer, at NIC-IRQ\u2019er helst ender der. Jeg overv\u00e5ger fjernhukommelsesadgang og sideflytninger, da de for\u00e5rsager spidsbelastninger i latenstiden. Hvis arbejdsbyrden skaleres kraftigt, kan det v\u00e6re fornuftigt med en replikation pr. NUMA-node med egen port\/frontend; i kombination med SO_REUSEPORT opn\u00e5r jeg meget stabile latenstider, s\u00e5 l\u00e6nge data- og kodestier forbliver node-lokale.<\/p>\n\n<h2>HTTP\/3 og fokus p\u00e5 UDP<\/h2>\n<p>Med HTTP\/3 (QUIC) drager jeg is\u00e6r fordel af SO_REUSEPORT i UDP-stien: Mange h\u00e5ndtryk og korte forbindelser fordeles uden en ekstra load balancer p\u00e5 brugerniveau. Jeg s\u00f8rger for, at UDP-bufferne er store nok, og tjekker drop-t\u00e6llerne for hver k\u00f8. Da QUIC-forbindelser logisk er bundet til 5-tuplen, forbliver fordelingen stabil, men jeg sikrer mig alligevel med konsistente retry-\/token-strategier, s\u00e5 valget af worker forbliver gennemsigtigt og ydeevneoptimeret.<\/p>\n\n<h2>Finjustering af eBPF til Reuseport<\/h2>\n<p>Med et Reuseport-BPF-program kan jeg styre socket-udv\u00e6lgelsen yderligere, f.eks. efter m\u00e5l-hostnavn (SNI), lokale prioriteter eller belastning pr. worker. Jeg bruger det kun, hvis standard-hash-fordelingen ikke er tilstr\u00e6kkelig, da yderligere logik \u00f8ger kompleksiteten. Ved fejlfinding tjekker jeg, om BPF-programmerne virkelig er indl\u00e6st og fungerer fejlfrit, og jeg har en fallback-strategi klar, hvis politikken skal afl\u00e6ses.<\/p>\n\n<h2>DDoS modstandsdygtighed og sikkerhed<\/h2>\n<p>SO_REUSEPORT \u00f8ger modtagelseskapaciteten \u2013 det er b\u00e5de en velsignelse og en risiko. Jeg indstiller rate-begr\u00e6nsninger og forbindelsesbegr\u00e6nsninger pr. worker, s\u00e5 de enkelte processer ikke bliver overbelastet p\u00e5 en ubalanceret m\u00e5de. I kombination med SYN-cookies, moderate timeouts og klare L7-begr\u00e6nsninger forhindrer jeg, at belastningsspidser binder ressourcerne permanent. Jeg opdeler logfilerne for hurtigere at kunne genkende misbrugsm\u00f8nstre pr. worker og bruger om n\u00f8dvendigt iptables\/nftables til at begr\u00e6nse ondsindede kilder p\u00e5 et tidligt tidspunkt.<\/p>\n\n<h2>Fejlfinding og verifikation<\/h2>\n<p>Jeg tjekker konfigurationen med ss -ltnp (TCP) eller ss -lunp (UDP) for at se, om der er flere lyttere p\u00e5 den samme IP\/port-kombination. Med perf, top\/htop og mpstat kontrollerer jeg, at CPU-udnyttelsen er j\u00e6vn. Netstat-\/ss-t\u00e6llere, dmesg-meddelelser og drop-statistikker fra netv\u00e6rkskortet (ethtool -S) viser, om k\u00f8er l\u00f8ber over. Til mere dybdeg\u00e5ende analyser giver tcpdump og Perf-begivenheder indsigt i accept-stier, retransmissioner og gentagelser. Det er vigtigt at holde \u00f8je med sammenh\u00e6ngen: Metrikker skal altid betragtes pr. worker, pr. CPU og pr. k\u00f8.<\/p>\n\n<h2>Undg\u00e5 almindelige konfigurationsfejl<\/h2>\n<ul>\n  <li>En worker uden SO_REUSEPORT opretter f\u00f8rst en forbindelse og blokerer alle andre.<\/li>\n  <li>0.0.0.0 og specifikke IP-adresser bruges blandet \u2013 lyttere placeres i separate grupper.<\/li>\n  <li>accept_mutex er aktiveret i Nginx p\u00e5 trods af reuseport \u2013 un\u00f8dvendig serialisering.<\/li>\n  <li>Uoverensstemmende backlogs: somaxconn er mindre end den backlog, der er angivet p\u00e5 serveren.<\/li>\n  <li>Ingen f\u00e6lles TLS-ticket-konfiguration \u2013 genoptagelsesraten styrtdykker.<\/li>\n  <li>RSS er forkert dimensioneret \u2013 IRQ-belastningen koncentreres om f\u00e5 kerner.<\/li>\n<\/ul>\n\n<h2>Kapacitetsplanl\u00e6gning: Arbejderantal og FD-gr\u00e6nser<\/h2>\n<p>Jeg afvejer antallet af workere i forhold til RAM pr. worker, \u00e5bne filer og antallet af forbindelser. For mange processer \u00f8ger kontekstskift og belastningen p\u00e5 cachen, mens for f\u00e5 g\u00e5r glip af parallelitet. Jeg indstiller filbeskrivelsesgr\u00e6nser gener\u00f8st og konsekvent (ulimit, systemd-gr\u00e6nser, h\u00e5rde\/bl\u00f8de gr\u00e6nser), da hver worker har brug for egne filbeskrivelser til sockets, logfiler og upstream-forbindelser. Desuden planl\u00e6gger jeg tilstr\u00e6kkeligt med midlertidige porte og overv\u00e5ger TIME_WAIT-m\u00e6ngden, s\u00e5 kortvarige spidsbelastninger ikke g\u00e5r til spilde.<\/p>\n\n<h2>Benchmarks: typiske faldgruber<\/h2>\n<p>Jeg varmer servere og cacher op, kalibrerer belastningsgeneratoren (ingen skjulte flaskehalse) og adskiller kontrol- og datanetv\u00e6rket. Testene k\u00f8rer l\u00e6nge nok til at m\u00e5le p99\/p999 stabilt, og jeg varierer t\u00e6nketider, keep-alive-frekvenser og TLS-parametre. Jeg logger kernel- og serverindstillinger, s\u00e5 senere k\u00f8rsler forbliver sammenlignelige. N\u00e5r jeg anvender eBPF-politikker, dokumenterer jeg deres version og effekt separat for ikke at blande \u00e5rsag og virkning sammen.<\/p>\n\n<h2>Tjekliste til starten<\/h2>\n\n<p>F\u00f8rst tjekker jeg kernelversionen og sikrer mig, at SO_REUSEPORT er tilg\u00e6ngelig og fungerer korrekt <strong>fastsat<\/strong> er. Derefter aktiverer jeg indstillingen i webserverkonfigurationen og konfigurerer det \u00f8nskede antal arbejdsprocesser. Jeg kontrollerer somaxconn, filbeskrivelsesgr\u00e6nser og NIC-k\u00f8er. Herefter udf\u00f8rer jeg belastningstests, sammenligner m\u00e5linger og gentager processen. Til sidst finjusterer jeg logningen, genstartsstrategien og <strong>affinitet<\/strong> fra.<\/p>\n\n<h2>Resum\u00e9<\/h2>\n\n<p>SO_REUSEPORT fjerner Accept-flaskehalsen, fordeler nye forbindelser via kernel-hash og opn\u00e5r bedre ydeevne p\u00e5 multicore-systemer <strong>Gennemstr\u00f8mning<\/strong> ud. Jeg bruger flere lyttere pr. port, undg\u00e5r \u201eThundering Herds\u201c-problemet og sparer mig for at skulle bruge en separat dispatcher. I Nginx opn\u00e5s dette med \u00bblisten \u2026 reuseport\u00ab og et passende antal workers. Sammen med CPU-affinitet, en ordentlig IRQ-fordeling og fornuftige buffere sikrer jeg en konstant <strong>Forsinkelser<\/strong> under belastning. Den, der gennemg\u00e5r, tester og finjusterer disse trin, \u00f8ger ydeevnen uden ekstra hardwareomkostninger i euro.<\/p>","protected":false},"excerpt":{"rendered":"<p>Find ud af, hvordan SO_REUSEPORT forbedrer din webservers ydeevne i Linux. L\u00e6r, hvordan denne socket-indstilling fungerer, og hvordan du bruger den i Nginx og andre tjenester.<\/p>","protected":false},"author":1,"featured_media":20883,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20890","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":"111","_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":"SO_REUSEPORT Linux","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":"20883","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20890","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=20890"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20890\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/20883"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=20890"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=20890"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=20890"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}