{"id":18881,"date":"2026-04-09T18:20:39","date_gmt":"2026-04-09T16:20:39","guid":{"rendered":"https:\/\/webhosting.de\/http-connection-reuse-keepalive-optimierung-serverperf-boost\/"},"modified":"2026-04-09T18:20:39","modified_gmt":"2026-04-09T16:20:39","slug":"http-forbindelse-genbrug-keepalive-optimering-serverperf-boost","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/http-connection-reuse-keepalive-optimierung-serverperf-boost\/","title":{"rendered":"Genbrug af HTTP-forbindelser og keep-alive-optimering: For\u00f8gelse af webserverens ydeevne"},"content":{"rendered":"<p>Jeg viser, hvordan <strong>Genbrug af HTTP-forbindelser<\/strong> og struktureret keep-alive-tuning reducerer overhead fra TCP- og TLS-h\u00e5ndtryk, s\u00e5 siderne reagerer hurtigere, og serverne skal g\u00f8re mindre. Med passende timeouts, gr\u00e6nser og protokolfunktioner reducerer jeg <strong>Forsinkelse<\/strong>, udj\u00e6vner spidsbelastninger og \u00f8ger gennemstr\u00f8mningen betydeligt.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<ul>\n  <li><strong>Keep-Alive<\/strong> reducerer h\u00e5ndtryk og forkorter <strong>Indl\u00e6sningstider<\/strong>.<\/li>\n  <li><strong>Timeouts<\/strong> og holde gr\u00e6nser <strong>Ressourcer<\/strong> effektiv.<\/li>\n  <li><strong>HTTP\/2<\/strong> og HTTP\/3 <strong>Genbrug<\/strong> gennem multiplexing.<\/li>\n  <li><strong>Samling af klienter<\/strong> s\u00e6nker backend<strong>Forsinkelse<\/strong>.<\/li>\n  <li><strong>Overv\u00e5gning<\/strong> g\u00f8r tuning til en succes <strong>m\u00e5lbar<\/strong>.<\/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\/04\/http-server-optimierung-9347.png\" alt=\"Effektiv HTTP-optimering i serverrummet\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvad betyder genbrug af HTTP-forbindelser?<\/h2>\n\n<p>Jeg bruger <strong>Genbrug af forbindelser<\/strong>, at sende flere HTTP-anmodninger over en enkelt TCP-forbindelse og dermed undg\u00e5 dyre genforbindelser. Hver ny forbindelse koster tre TCP-pakker plus et muligt TLS-h\u00e5ndtryk, hvilket sparer tid og penge. <strong>CPU<\/strong> spiser. Hvis linjen forbliver \u00e5ben, k\u00f8rer efterf\u00f8lgende anmodninger p\u00e5 den samme socket og sparer rundture. Websteder med mange sm\u00e5 ressourcer som CSS, JS og billeder nyder is\u00e6r godt af det, fordi ventetiden pr. objekt reduceres. I HTTP\/1.1 signalerer headeren \u201cConnection: keep-alive\u201d genbrug, hvilket m\u00e6rkbart reducerer ventetiden og stabiliserer gennemstr\u00f8mningen.<\/p>\n\n<h2>Hvorfor Keep-Alive forbedrer webserverens ydeevne<\/h2>\n\n<p>Jeg stoler p\u00e5 <strong>Keep-Alive<\/strong>-tuning, fordi det reducerer overhead i kernen og TLS, hvilket g\u00f8r det muligt at sende mere nyttelast pr. sekund gennem linjen. I test \u00f8ges den effektive gennemstr\u00f8mning ofte med op til 50 procent, da handshakes elimineres, og <strong>CPU<\/strong> udf\u00f8rer f\u00e6rre kontekstskift. Samtidig reagerer siderne hurtigere, da browsere hurtigt kan genindl\u00e6se yderligere objekter. Korte timeouts forhindrer inaktive forbindelser i at optage RAM, og gr\u00e6nser for keepalive_requests sikrer stabilitet. P\u00e5 den m\u00e5de holder jeg antallet af aktive sockets i den gr\u00f8nne zone og undg\u00e5r flaskehalse under spidsbelastning.<\/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\/04\/http-opt-meeting-1045.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Konfiguration p\u00e5 serversiden: Nginx, Apache og proxyer<\/h2>\n\n<p>Jeg satte <strong>Nginx<\/strong> s\u00e5 timeouts er korte nok til at spare RAM, men lange nok til, at browsere kan hente flere objekter efter hinanden. For typiske hjemmesider klarer jeg mig godt med 60-120 sekunders tomgangstimeout og 50-200 foresp\u00f8rgsler pr. forbindelse, som jeg sammenligner med reelle trafikm\u00f8nstre. Et eksempel viser, hvordan jeg starter og derefter finjusterer. Via linket <a href=\"https:\/\/webhosting.de\/da\/http-keepalive-timeout-konfiguration-af-serverens-ydeevne\/\">Konfigurer keep-alive timeout<\/a> Jeg dykker ned i detaljer som \u00e5bne filbeskrivelser og acceptk\u00f8er. For reverse proxies aktiverer jeg proxy_http_version 1.1, s\u00e5 keep-alive sendes videre p\u00e5 en ren m\u00e5de, og backends f\u00e5r gavn af genbrug.<\/p>\n\n<pre><code># Nginx (Frontend \/ Reverse Proxy)\nkeepalive_timeout 65s;\nkeepalive_requests 100;\n\n# Proxy til upstream\nproxy_http_version 1.1;\nproxy_set_header Forbindelse \"\";\n\n# Apache (eksempel)\nKeepAlive On\nMaxKeepAliveRequests 100\nKeepAliveTimeout 5\n<\/code><\/pre>\n\n<h2>TLS, HTTP\/2 og HTTP\/3: protokoller, der styrker genbrug<\/h2>\n\n<p>Jeg kombinerer <strong>Keep-Alive<\/strong> med TLS 1.3, session resumption og OCSP stapling, s\u00e5 forbindelser er tilg\u00e6ngelige hurtigere. I HTTP\/2 bundter jeg mange streams p\u00e5 en enkelt forbindelse, hvilket eliminerer head-of-line-forsinkelser p\u00e5 applikationsniveau. Effekten \u00f8ges med <strong>Multiplexing<\/strong>, fordi browsere anmoder om ressourcer parallelt uden at skulle oprette nye sockets. For en velbegrundet kategorisering, se venligst <a href=\"https:\/\/webhosting.de\/da\/http2-multiplexing-vs-http11-performance-baggrund-optimering\/\">HTTP\/2 multiplexing<\/a>, som tydeligt viser forskellene til HTTP\/1.1. HTTP\/3 med QUIC giver ogs\u00e5 0-RTT-start for idempotente anmodninger og reagerer m\u00e6rkbart hurtigere i tilf\u00e6lde af pakketab.<\/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\/04\/http-connection-reuse-8542.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Optimering p\u00e5 klientsiden: Node.js og Python<\/h2>\n\n<p>Jeg aktiverer <strong>Keep-Alive<\/strong> ogs\u00e5 i klienten, s\u00e5 API- og backend-kald kr\u00e6ver mindre etablering af forbindelse. I Node.js bruger jeg en https.agent med connection pooling, som reducerer ventetiden og fremskynder time-to-first-byte. Python med requests.Session() g\u00f8r det samme p\u00e5 en enkel m\u00e5de, hvilket g\u00f8r tjenesterne mere stabile. Det holder transportvejene korte og sparer rundture i begge retninger. Det resulterer i mere ensartede svartider og en m\u00e5lbart lavere <strong>Serverbelastning<\/strong>.<\/p>\n\n<pre><code>\/\/ Node.js\nconst https = require('https');\nconst httpsAgent = new https.Agent({\n  keepAlive: true,\n  keepAliveMsecs: 60000,\n  maxSockets: 50\n});\n\n\/\/ Anvendelse: fetch \/ axios \/ native https med httpsAgent\n\n# Python\nimport anmodninger\nsession = requests.Session() # Genbrug og pooling\nr = session.get('https:\/\/api.example.com\/data') # f\u00e6rre h\u00e5ndtryk\n<\/code><\/pre>\n\n<h2>Typiske v\u00e6rdier og deres effekt<\/h2>\n\n<p>Jeg starter med konservativ <strong>V\u00e6rdier<\/strong> og m\u00e5ler, om forbindelserne har tendens til at h\u00e6nge i tomgang eller lukke for tidligt. Hvis jeg forventer spidsbelastninger, forkorter jeg timeouts for at holde RAM fri uden at tvinge browsere til konstant at oprette forbindelse igen. Hvis paralleliteten er h\u00f8j, s\u00e6tter jeg de maksimale filbeskrivelser h\u00f8jt nok til at undg\u00e5 acceptflaskehalse. F\u00f8lgende tabel giver et hurtigt overblik over, hvordan jeg kommer i gang, og hvad indstillingerne g\u00f8r. Derefter finjusterer jeg trinvis og holder n\u00f8je \u00f8je med metrics for <strong>Rettelser<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parametre<\/th>\n      <th>Nginx<\/th>\n      <th>Apache<\/th>\n      <th>Typisk startv\u00e6rdi<\/th>\n      <th>Effekt<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Inaktiv timeout<\/td>\n      <td>keepalive_timeout<\/td>\n      <td>KeepAliveTimeout<\/td>\n      <td>60\u2013120 s<\/td>\n      <td>Udligner genbrug og RAM-forbrug<\/td>\n    <\/tr>\n    <tr>\n      <td>Anmodninger pr. forbindelse<\/td>\n      <td>keepalive_requests<\/td>\n      <td>MaxKeepAliveRequests<\/td>\n      <td>50-200<\/td>\n      <td>Stabiliserer udnyttelsen pr. stikkontakt<\/td>\n    <\/tr>\n    <tr>\n      <td>Proxy-version<\/td>\n      <td>proxy_http_version<\/td>\n      <td>\u2013<\/td>\n      <td>1.1<\/td>\n      <td>G\u00f8r det muligt at sende keep-alive videre<\/td>\n    <\/tr>\n    <tr>\n      <td>\u00c5bn deskriptorer<\/td>\n      <td>worker_rlimit_nofile<\/td>\n      <td>ulimit -n<\/td>\n      <td>&gt;= 65535<\/td>\n      <td>Forhindrer mangel p\u00e5 stikkontakter<\/td>\n    <\/tr>\n    <tr>\n      <td>Accepter k\u00f8<\/td>\n      <td>net.core.somaxconn<\/td>\n      <td>LytBacklog<\/td>\n      <td>512-4096<\/td>\n      <td>Reducerer fald ved spidsbelastninger<\/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\/04\/webserver_perf_3498.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Overv\u00e5gning og belastningstest: Metrikker, der t\u00e6ller<\/h2>\n\n<p>Jeg vurderer <strong>Genbrug<\/strong>-resultater med wrk eller ApacheBench og sammenhold dem med logfiler og systemm\u00e5linger. \u00c5bne sockets, ledige sockets, ventende foresp\u00f8rgsler og fejlkoder, der indikerer flaskehalse, er vigtige. Hvis antallet af inaktive forbindelser stiger, s\u00e6nker jeg timeouts eller reducerer keepalive_requests moderat. Hvis forbindelser afbrydes for ofte, \u00f8ger jeg gr\u00e6nserne eller tjekker, om backends reagerer for langsomt. Det giver mig mulighed for hurtigt at finde det punkt, hvor latency, throughput og <strong>Ressourcer<\/strong> passer godt sammen.<\/p>\n\n<h2>WordPress-praksis: F\u00e6rre anmodninger, hurtigere f\u00f8rste maling<\/h2>\n\n<p>Jeg reducerer HTTP-anmodninger med <strong>CSS\/JS<\/strong> bundt, bruge ikoner som SVG-sprites og levere skrifttyper lokalt. Sammen med browserens caching reduceres antallet af netv\u00e6rksoverf\u00f8rsler ved genbes\u00f8g drastisk. Det skaber st\u00f8rre mulighed for genbrug, fordi browsere kr\u00e6ver f\u00e6rre nye sockets. Hvis du vil dykke dybere ned, kan du finde praktiske trin i <a href=\"https:\/\/webhosting.de\/da\/guide-til-optimering-af-webserverens-ydeevne\/\">Guide til indstilling af Keep-Alive<\/a>, som forklarer indstillingsstier fra timeout til worker-ops\u00e6tning. I sidste ende er det, der t\u00e6ller, at siderne indl\u00e6ses m\u00e6rkbart hurtigere, og at <strong>Serverbelastning<\/strong> forbliver forudsigelig.<\/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\/04\/webserverperformance1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Skalering og systemressourcer<\/h2>\n\n<p>Jeg tjekker <strong>CPU<\/strong>-profiler, hukommelsesfodaftryk pr. arbejder og netv\u00e6rkskortet, f\u00f8r jeg \u00f8ger gr\u00e6nserne. H\u00f8jere parallelitet er kun nyttigt, hvis hvert lag har nok buffere og deskriptorer. NUMA-affinitet, IRQ-distribution og hurtige TLS-implementeringer giver yderligere reserver. Med containere er jeg opm\u00e6rksom p\u00e5 \u00e5bne filgr\u00e6nser og h\u00e5rde gr\u00e6nser for v\u00e6rten, som ellers bremser genbrug. P\u00e5 den m\u00e5de undg\u00e5r jeg flaskehalse, der hurtigt bliver m\u00e6rkbare med voksende trafik og spilder v\u00e6rdifulde ressourcer. <strong>Str\u00f8m<\/strong> omkostninger.<\/p>\n\n<h2>Fejlbilleder og fejlfinding<\/h2>\n\n<p>Jeg anerkender <strong>Fejl<\/strong> Jeg l\u00e6gger ofte m\u00e6rke til m\u00f8nstre: for mange TIME_WAIT-sokler, stigende 502\/504 eller pludselige RPS-kn\u00e6k. Derefter tjekker jeg, om backends accepterer keep-alive, og om proxy-headers er sat korrekt. Forkerte idle timeouts udl\u00f8ser ofte k\u00e6dereaktioner p\u00e5 individuelle hop, som jeg retter op p\u00e5 ved at indstille ensartede v\u00e6rdier. TLS-problemer viser sig som spidser i handshake_time, som sessionsgenoptagelse eller 1.3-optimeringer afhj\u00e6lper. Med m\u00e5lrettede justeringer stabiliserer jeg k\u00e6den fra edge til app-serveren og holder <strong>Svartider<\/strong> p\u00e5lidelig.<\/p>\n\n<h2>Hold timeouts p\u00e5 tv\u00e6rs af skift konsistente<\/h2>\n\n<p>Jeg udligner <strong>Timeouts for inaktivitet og aktivitet<\/strong> p\u00e5 tv\u00e6rs af alle hop: CDN\/WAF, load balancer, reverse proxy og applikation. En origin-timeout, der er for kort, afbryder forbindelser, mens browseren stadig indl\u00e6ses; en edge-timeout, der er for lang, fylder RAM med inaktive sockets. Jeg planl\u00e6gger derfor i kaskader: Edge lidt <em>kortere<\/em> som browser inaktiv, proxy i midten, l\u00e6ngste backend-timeout. P\u00e5 den m\u00e5de undg\u00e5r jeg RST'er og forhindrer dyre TLS-forbindelser i at blive afbrudt uden grund.<\/p>\n\n<pre><code># Nginx: pr\u00e6cise timeouts og upstream-genbrug\nclient_header_timeout 10s;\nclient_body_timeout 30s;\nsend_timeout 15s;\n\nproxy_read_timeout 60s;\nproxy_send_timeout 60s;\nproxy_socket_keepalive on; # Registrerer d\u00f8d peer hurtigere\n\nupstream backend_pool {\n  server app1:8080;\n  server app2:8080;\n  keepalive 64; # Cache inaktive upstream-forbindelser\n  keepalive_timeout 60s; # (fra Nginx-versioner med upstream-timeout)\n  keepalive_requests 1000;\n}\n<\/code><\/pre>\n\n<p>Jeg skelner mellem <strong>HTTP-Keep-Alive<\/strong> Fra <strong>TCP-Keepalive<\/strong> (SO_KEEPALIVE). Jeg bruger sidstn\u00e6vnte specifikt p\u00e5 proxy-sokler til at genkende h\u00e6ngende fjernstationer uden at afslutte HTTP-genbrug un\u00f8digt.<\/p>\n\n<h2>Finjustering af HTTP\/2 og HTTP\/3: korrekt brug af multiplexing<\/h2>\n\n<p>Jeg indstiller HTTP\/2, s\u00e5 streams k\u00f8rer effektivt parallelt uden at generere head-of-line p\u00e5 serveren. For at g\u00f8re dette begr\u00e6nser jeg det maksimale antal streams pr. session og holder idle timeouts korte, s\u00e5 glemte sessioner ikke bliver efterladt. Jeg bruger prioritering til at <strong>Kritiske aktiver<\/strong> og s\u00f8rg for, at HTTP\/3 har en ren 0-RTT-ops\u00e6tning kun til idempotente anmodninger.<\/p>\n\n<pre><code># Nginx HTTP\/2-optimering\nhttp2_max_concurrent_streams 128;\nhttp2_idle_timeout 30s; # Inaktivitet p\u00e5 H2-niveau\nhttp2_max_field_size 16k; # Header-beskyttelse (se Sikkerhed)\nhttp2_max_header_size 64k;\n<\/code><\/pre>\n\n<p>Med <strong>Sammenl\u00e6gning af forbindelser<\/strong> (H2\/H3) kan en browser bruge flere v\u00e6rtsnavne via <em>en<\/em> forbindelse, hvis certifikat-SAN'erne og IP\/konfigurationen matcher. Jeg udnytter dette ved at konsolidere statiske underdom\u00e6ner og v\u00e6lge certifikater, der d\u00e6kker flere v\u00e6rter. Det sparer mig for yderligere handshakes og portkonkurrence.<\/p>\n\n<h2>Et overblik over kerne- og socketparametre<\/h2>\n\n<p>Jeg sikrer ogs\u00e5 Reuse p\u00e5 <strong>Kernel-niveau<\/strong> s\u00e5 der ikke opst\u00e5r mangel p\u00e5 port og socket. Flygtige portomr\u00e5der, FIN\/TIME_WAIT-adf\u00e6rd og keepalive-probing har direkte indflydelse p\u00e5 stabilitet og handshake-hastighed.<\/p>\n\n<pre><code># \/etc\/sysctl.d\/99-tuning.conf (eksempler, test med forsigtighed)\nnet.ipv4.ip_local_port_range = 10240 65535\nnet.ipv4.tcp_fin_timeout = 15\nnet.ipv4.tcp_keepalive_time = 600\nnet.ipv4.tcp_keepalive_intvl = 30\nnet.ipv4.tcp_keepalive_probes = 5\nnet.core.netdev_max_backlog = 4096\n<\/code><\/pre>\n\n<p>Jeg undg\u00e5r risikable justeringer som f.eks. tankel\u00f8s aktivering af <code>tcp_tw_reuse<\/code> p\u00e5 offentligt tilg\u00e6ngelige servere. Endnu vigtigere, <strong>Odds for genbrug<\/strong> s\u00e5 der ikke er mange kortvarige forbindelser i f\u00f8rste omgang. Under tung belastning skalerer jeg ogs\u00e5 IRQ-distribution og CPU-affinitet, s\u00e5 netv\u00e6rksinterrupts ikke samles i klynger og skaber latency-toppe.<\/p>\n\n<h2>Sikkerhed og beskyttelse mod misbrug uden at s\u00e6nke farten Genbrug<\/h2>\n\n<p>Keep-Alive inviterer angribere til at <strong>Slowloris<\/strong>-varianter eller HTTP\/2-misbrug, hvis der mangler gr\u00e6nser. Jeg h\u00e6rder headerst\u00f8rrelser og anmodningshastigheder uden at forstyrre legitime genbrugsm\u00f8nstre. I mods\u00e6tning til <em>Hurtig nulstilling<\/em>-m\u00f8nster i H2 s\u00e6tter jeg gr\u00e6nser for samtidige streams og RST-hastigheder og logger i\u00f8jnefaldende klienter.<\/p>\n\n<pre><code># Nginx: Regler for beskyttelse\nlarge_client_header_buffers 4 8k;\nclient_body_buffer_size 128k;\n\nlimit_conn_zone $binary_remote_addr zone=perip:10m;\nlimit_conn perip 50;\n\nlimit_req_zone $binary_remote_addr zone=periprate:10m rate=20r\/s;\nlimit_req zone=periprate burst=40 nodelay;\n\n# H2-specifik allerede ovenfor: http2_max_concurrent_streams, header limits\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/serverraum-optimierung-5743.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<p>Jeg bruger ogs\u00e5 <strong>yndefuld<\/strong> Nedlukninger, s\u00e5 keep-alive-forbindelser l\u00f8ber rent ud under udrulninger, og der ikke opst\u00e5r klientfejl.<\/p>\n\n<pre><code># Nginx: Ryd forbindelser p\u00e5 en ren m\u00e5de\nworker_shutdown_timeout 10s;\n<\/code><\/pre>\n\n<h2>Load balancere, CDN og upstreams: genbrug i hele k\u00e6den<\/h2>\n\n<p>Jeg s\u00f8rger for, at <strong>mellem<\/strong> LB\/proxy og backend genbruges. For at g\u00f8re dette driver jeg upstream-pools med tilstr\u00e6kkelige slots og bruger sticky eller konsistente hashing-strategier, hvis der er behov for sessioner i backend. Jeg reducerer belastningen p\u00e5 CDN'er ved at bruge nogle f\u00e5, langvarige <em>Oprindelse<\/em>-forbindelser og begr\u00e6ns det maksimale antal forbindelser pr. POP, s\u00e5 app-serverne ikke drukner i for mange sm\u00e5 sockets.<\/p>\n\n<p>Vigtige er <strong>Homogene timeouts for inaktivitet<\/strong> langs stien: Edge m\u00e5 ikke afbryde forbindelser tidligere end Origin, ellers vil multiplexing-sessioner blive un\u00f8dvendigt genetableret. Med HTTP\/3 tager jeg h\u00f8jde for, at notebook- og mobilklienter skifter IP oftere; jeg planl\u00e6gger derfor tolerante, men begr\u00e6nsede inaktivitetstider.<\/p>\n\n<h2>Uddyb klient-pooling: Node.js, Python, gRPC<\/h2>\n\n<p>P\u00e5 klientsiden tager jeg mig af fornuftige <strong>Pooling<\/strong> og klare gr\u00e6nser, s\u00e5 der ikke er stampedes eller l\u00e6kager. I Node.js s\u00e6tter jeg gr\u00e6nser for fri socket og timeouts for inaktivitet, s\u00e5 forbindelserne forbliver varme, men ikke forbliver \u00e5bne for evigt.<\/p>\n\n<pre><code>\/\/ Finjustering af Node.js-agenten\nconst https = require('https');\nconst agent = new https.agent({\n  keepAlive: true,\n  keepAliveMsecs: 60000,\n  maxSockets: 100,\n  maxFreeSockets: 20\n});\n\/\/ axios\/fetch: httpsAgent: agent\n<\/code><\/pre>\n\n<pre><code># Python-anmodninger: st\u00f8rre pulje pr. v\u00e6rt\nimport anmodninger\nfra requests.adapters import HTTPAdapter\n\nsession = requests.session()\nadapter = HTTPAdapter(pool_connections=50, pool_maxsize=200, max_retries=0)\nsession.mount('https:\/\/', adapter)\nsession.mount('http:\/\/', adapter)\n<\/code><\/pre>\n\n<p>For <strong>asynkron<\/strong> (aiohttp) begr\u00e6nser jeg det maksimale antal sockets og bruger DNS-caching for at holde ventetiden nede. Med <strong>gRPC<\/strong> (H2) s\u00e6tter jeg keep-alive-pings moderat, s\u00e5 lange inaktivitetsfaser ikke f\u00f8rer til afbrydelse af forbindelsen uden at oversv\u00f8mme netv\u00e6rk.<\/p>\n\n<h2>Metrikker og m\u00e5lv\u00e6rdier for tuningsl\u00f8jfer<\/h2>\n\n<p>Jeg styrer tuningen iterativt med n\u00f8gletal, der g\u00f8r genbrug synligt:<\/p>\n<ul>\n  <li><strong>Genbrugskvote<\/strong> (anmodninger\/forbindelse) separat for frontend og upstream.<\/li>\n  <li><strong>TLS-h\u00e5ndtryk\/s<\/strong> vs. anmodninger\/s - M\u00e5l: Reducere andelen af h\u00e5ndtryk.<\/li>\n  <li><strong>p95\/p99 latenstid<\/strong> for TTFB og i alt.<\/li>\n  <li><strong>Inaktive forbindelser<\/strong> og deres levetid.<\/li>\n  <li><strong>Fejlprofiler<\/strong> (4xx\/5xx), nulstillinger, timeouts.<\/li>\n  <li><strong>TIME_WAIT\/FIN_WAIT<\/strong>-t\u00e6ller og kortvarig portudnyttelse.<\/li>\n<\/ul>\n<p>Et simpelt m\u00e5lbillede: <em>TLS-h\u00e5ndtryk\/s<\/em> stabil langt under <em>Anmodninger\/s<\/em>, genbrugshastighed i H1-omr\u00e5det &gt;= 20-50 afh\u00e6ngigt af objektst\u00f8rrelse, for H2\/H3 flere samtidige streams pr. session uden overbelastning.<\/p>\n\n<h2>Front-end-strategier, der fremmer genbrug<\/h2>\n\n<p>Jeg undg\u00e5r <strong>Deling af dom\u00e6ner<\/strong> med H2\/H3, konsolidere hosts og bruge preload\/preconnect selektivt for at spare dyre handshakes, hvor de er uundg\u00e5elige. Jeg indl\u00e6ser store billeder p\u00e5 en moderne og komprimeret m\u00e5de, s\u00e5 b\u00e5ndbredden ikke bliver en flaskehals, der un\u00f8digt blokerer keep-alive-slots. Jeg minimerer cookies for at holde overskrifterne sm\u00e5 og sende flere objekter effektivt over de samme sessioner.<\/p>\n\n<h2>Overvej mobil- og NAT-netv\u00e6rk<\/h2>\n\n<p>I mobilradio- og NAT-milj\u00f8er <strong>Tidsfrister for inaktivitet<\/strong> ofte kortere. Jeg holder derfor serverens inaktivitet moderat og accepterer, at klienter genopretter forbindelsen oftere. Med sessionsgenoptagelse og 0-RTT (H3) er genforbindelserne stadig hurtige. P\u00e5 serversiden hj\u00e6lper TCP keep-alive-probes p\u00e5 proxy-sokler med hurtigt at komme af med d\u00f8de stier.<\/p>\n\n<h2>Udrulninger og h\u00f8j tilg\u00e6ngelighed<\/h2>\n\n<p>Til implementeringer administrerer jeg forbindelser <strong>bl\u00f8d<\/strong> slukket: Stop nye acceptationer, vent p\u00e5 eksisterende keep-alive-sockets, og afslut f\u00f8rst derefter processerne. Jeg placerer forbindelsesdr\u00e6ning bag LB'er, s\u00e5 multiplexing-sessioner ikke afsluttes midt i str\u00f8mmen. Jeg holder sundhedstjek aggressive, men idempotente, for at kunne genkende fejl tidligt og omstrukturere pools i god tid.<\/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\/04\/http-connection-reuse-8542.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Opsummering til hurtig succes<\/h2>\n\n<p>Jeg stoler p\u00e5 <strong>HTTP<\/strong> Genbrug af forbindelser, korte timeouts og fornuftige gr\u00e6nser, s\u00e5 forbindelserne forbliver produktive og ikke binder ressourcer, n\u00e5r de er inaktive. Moderne protokoller som HTTP\/2 og HTTP\/3 forst\u00e6rker effekten, mens client pooling aflaster backends. Med overv\u00e5gning opdager jeg tidligt, hvor sockets er inaktive eller for knappe, og justerer v\u00e6rdierne iterativt. Til WordPress og lignende stakke kombinerer jeg genbrug med caching, bundling af aktiver og lokalt hostede skrifttyper. Det resulterer i hurtige sider, j\u00e6vne belastningskurver og en <strong>Webserver<\/strong>-pr\u00e6stationer, hvilket er tydeligt p\u00e5 alle parametre.<\/p>","protected":false},"excerpt":{"rendered":"<p>Genbrug af HTTP-forbindelser og keep-alive-optimering \u00f8ger webserverens ydeevne enormt. F\u00e5 tips til indstilling af mindre ventetid og h\u00f8jere gennemstr\u00f8mning.<\/p>","protected":false},"author":1,"featured_media":18874,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-18881","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":"548","_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":"HTTP Connection Reuse","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":"18874","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/18881","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=18881"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/18881\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/18874"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=18881"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=18881"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=18881"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}