{"id":21459,"date":"2026-09-16T15:03:59","date_gmt":"2026-09-16T13:03:59","guid":{"rendered":"https:\/\/webhosting.de\/nginx-keepalive-requests-optimieren-webserver-performance-tuning\/"},"modified":"2026-09-16T15:03:59","modified_gmt":"2026-09-16T13:03:59","slug":"nginx-keepalive-verzoeken-optimaliseren-prestaties-van-de-webserver-afstemmen","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/nginx-keepalive-requests-optimieren-webserver-performance-tuning\/","title":{"rendered":"NGINX Keepalive-verzoeken optimaliseren: optimale webserverprestaties door gerichte afstemming"},"content":{"rendered":"<p>Met <strong>nginx keepalive<\/strong> Ik verlaag de kosten voor het opbouwen van verbindingen, verminder het aantal handshakes en versnel de responstijden merkbaar. Doelgericht afgestemde time-outs, verzoeklimieten per verbinding en hergebruikte upstream-sockets leveren meetbare prestatiewinst op zonder nieuwe hardware.<\/p>\n\n<h2>Centrale punten<\/h2>\n\n<ul>\n  <li><strong>Time-outs<\/strong> Verstandig kiezen: de inactieve tijd zo kort als nodig, zo lang als nuttig.<\/li>\n  <li><strong>Verzoeken<\/strong> Beperken per verbinding: duurzame sockets, geen vastlopers.<\/li>\n  <li><strong>Upstream-pools<\/strong> Activeren: permanente backend-verbindingen per worker.<\/li>\n  <li><strong>Werknemer<\/strong> en verbindingen afstemmen: voldoende slots voor inactieve en actieve clients.<\/li>\n  <li><strong>Controle<\/strong> instellen: connectiepercentage, latentie en fouten in de gaten houden.<\/li>\n<\/ul>\n\n<h2>NGINX Keepalive: effecten en kosten<\/h2>\n\n<p>Ik houd TCP-verbindingen bewust open, omdat <strong>Handdrukken<\/strong> duur zijn en bij veel kleine verzoeken de overhand hebben. Persistente sockets besparen niet alleen RTT\u2019s, ze zorgen ook voor een gelijkmatiger CPU-gebruik, omdat de cryptografie voor TLS minder vaak wordt gestart. Elke open verbinding neemt echter <strong>Bronnen<\/strong>, zoals bestandsdescriptoren en buffers, die ik in de gaten moet houden. De kunst zit hem in de juiste balans: voldoende hergebruik voor snelheid, voldoende capaciteit voor nieuwe verbindingen bij pieken in het verkeer. Wie die balans weet te vinden, bereikt constant lage TTFB-waarden en een snelle gebruikerservaring.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-keepalive-optimierung-4271.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>HTTP\/2 en HTTP\/3: multiplexing en keepalive<\/h2>\n\n<p>Met <strong>HTTP\/2<\/strong> en <strong>HTTP\/3<\/strong> daalt het aantal benodigde verbindingen per client, omdat er meerdere streams via \u00e9\u00e9n verbinding lopen. Keepalive blijft echter van belang: die ene verbinding moet betrouwbaar open blijven, anders gaat het voordeel van multiplexing verloren door het veelvuldig opnieuw tot stand brengen van verbindingen.<\/p>\n<p>Ik let op de specifieke idle-parameters voor moderne protocollen en zorg ervoor dat de waarden aansluiten bij de time-outs van mijn client. Voor tests begin ik met gematigde waarden en verhoog ik deze bij een stabiele belasting, totdat het aantal herverbindingen afneemt en de latentie constant blijft.<\/p>\n\n<pre><code>http {\n    # HTTP\/2: time-out voor inactieve, maar geopende streams\n    http2_idle_timeout 60s;\n\n    # HTTP\/3\/QUIC: vergelijkbare logica voor op UDP gebaseerde verbindingen\n    http3_idle_timeout 60s;\n\n    # TLS-hervatting vermindert de kosten van de handshake bij nieuwe verbindingen\n    ssl_session_cache shared:SSL:50m;\n    ssl_session_timeout 1d;\n    ssl_session_tickets off;\n}\n<\/code><\/pre>\n\n<p>Multiplexing vermindert het aantal benodigde parallelle TCP\/QUIC-verbindingen, maar niet het belang van de <strong>juiste time-outs<\/strong>. Wie HTTP\/2\/3 gebruikt, kan de time-outs aan de clientzijde vaak wat ruimer instellen, omdat veel kleine bronnen via hetzelfde kanaal worden verzonden. Belangrijk: meetbaar blijven <em>Tijd tot eerste byte<\/em>, foutpercentages en actieve streams per verbinding.<\/p>\n\n<h2>Client-Keepalive correct instellen<\/h2>\n\n<p>Voor browserclients regel ik hergebruik via <strong>keepalive_timeout<\/strong> en <strong>keepalive_requests<\/strong>, zodat sockets lang genoeg actief blijven zonder eindeloos te blokkeren. Als uitgangspunt hanteer ik een time-out van 30\u201360 seconden en 100\u2013300 verzoeken per verbinding; daarna pas ik de instellingen aan op basis van de statistieken. Een gedetailleerd overzicht vind je hier <a href=\"https:\/\/webhosting.de\/nl\/http-keepalive-timeout-serverprestaties-configuratie\/\">Handleiding voor keepalive-time-out<\/a>, waarin de gevolgen voor de latentie en de serverbronnen worden uitgelegd. Kortere time-outs zijn geschikt bij zeer veel korte verzoeken, terwijl langere tijdsvensters helpen bij periodieke API-toegangen. Om te beginnen stel ik duidelijke standaardinstellingen in en meet ik het effect op open verbindingen en foutmeldingen.<\/p>\n\n<pre><code>http {\n    # Inactieve verbindingen met de client\n    keepalive_timeout 60s;\n    # Maximum aantal verzoeken per TCP-verbinding\n    keepalive_requests 200;\n\n    # Optioneel: Keep-Alive uitschakelen voor bepaalde clients (legacy-bugs)\n    # keepalive_disable msie6;\n}\n<\/code><\/pre>\n\n<h2>Upstream-keepalive in de reverse proxy<\/h2>\n\n<p>Tussen NGINX en de backend-apps maak ik gebruik van persistente upstream-sockets, omdat de verbinding met PHP-FPM, Node.js of Python-services ook <strong>Latency<\/strong> kost. Hiervoor activeer ik in de upstream-pool een passend aantal herbruikbare verbindingen per worker. Belangrijk zijn HTTP\/1.1 naar de server toe en een lege Connection-header, anders verbreekt het \u201eclose\u201c-verzoek van de client de backend-persistentie. Ik baseer me op het aantal gelijktijdige verzoeken en stel de pool zo in dat er nauwelijks nieuwe verbindingen tot stand komen. Zo daalt de backend-connect-tijd en levert de gehele keten snellere <strong>Antwoorden<\/strong>.<\/p>\n\n<pre><code>upstream backend {\n    server 127.0.0.1:9000;\n    keepalive 64; # Aantal persistente upstream-verbindingen per worker\n}\n\nserver {\n    location \/ {\n proxy_pass http:\/\/backend;\n        proxy_http_version 1.1;\n proxy_set_header Connection \"\";\n # TCP-keepalive voor upstream-sockets op OS-niveau\n proxy_socket_keepalive on;\n    }\n}\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx_optimierung_miniature_4891.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Dimensionering van het zwembad en het budget voor aansluitingen<\/h2>\n\n<p>Ik bereken pools op realistische wijze: het aantal persistente upstream-verbindingen wordt bepaald door <strong>worker_processes \u00d7 keepalive<\/strong> per upstream. Wie 8 workers en keepalive 64 gebruikt, houdt tot 512 sockets per upstream open \u2013 per instantie. Achter een load balancer of bij meerdere upstream-doelen kan dat snel oplopen.<\/p>\n<p>Mijn streefwaarde: voldoende open sockets, zodat het grootste deel van de verzoeken <em>zonder nieuwe Connect<\/em> wordt bediend, maar er is nog ruimte voor pieken. Ik houd de statistiek \u201enieuwe upstream-verbindingen per seconde\u201c in de gaten en verlaag deze totdat verdere vergrotingen van de poolgrootte geen noemenswaardige verbetering van de latentie meer opleveren.<\/p>\n<p>Ik houd ook rekening met <strong>Eerlijkheid<\/strong>: Te grote pools kunnen nieuw binnenkomende clients benadelen, omdat worker-slots worden bezet door inactieve verbindingen. Een gematigde limiet in combinatie met actieve monitoring werkt meestal sneller dan het op goed geluk instellen van maximale waarden.<\/p>\n\n<h2>Fijnafstemming: time-outs en verzoeklimieten<\/h2>\n\n<p>Ik combineer de time-out en het verzoeklimiet zodanig dat verbindingen effectief opnieuw worden gebruikt, zonder dat dit leidt tot <strong>Langlaufer<\/strong> te worden. Hoge waarden op beide assen minimaliseren het aantal \u2018connects\u2019, maar verhogen het risico op vastgelopen sockets bij netwerkproblemen. Lage waarden zorgen voor nieuwe verbindingen, maar kosten extra handshakes. Ik ga stap voor stap te werk, houd fouten in de gaten en pas de instellingen met tussenpozen aan. De volgende tabel toont zinvolle startbereiken voor verschillende gebruikspatronen en biedt een compact <strong>Ori\u00ebntatie<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Scenario<\/th>\n      <th>keepalive_timeout<\/th>\n      <th>keepalive_requests<\/th>\n      <th>Tip<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Veel korte paginabezoeken<\/td>\n      <td>10\u201330 s<\/td>\n      <td>100-300<\/td>\n      <td>Snelle hergebruikstijd, lage idle-binding<\/td>\n    <\/tr>\n    <tr>\n      <td>Typische website<\/td>\n      <td>60\u2013120 s<\/td>\n      <td>200\u2013400<\/td>\n      <td>Goede gemiddelde scores voor Assets en HTML<\/td>\n    <\/tr>\n    <tr>\n      <td>API met periodieke oproepen<\/td>\n      <td>60\u2013120 s<\/td>\n      <td>300\u20131000<\/td>\n      <td>Hoger hergebruikpercentage voor klanten<\/td>\n    <\/tr>\n    <tr>\n      <td>Interne diensten \/ Gateways<\/td>\n      <td>30\u201390 seconden<\/td>\n      <td>500\u20131000+<\/td>\n      <td>Constantheid is belangrijker dan een minimaal aantal connects<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Worker-tuning en verbindingen<\/h2>\n\n<p>Ik heb <strong>werker_processen<\/strong> op 'auto' of op het aantal CPU-kernen en zorg voor voldoende <strong>werker_verbindingen<\/strong> omdat inactieve sockets slots bezetten. Te lage limieten verhinderen dat er nieuwe verbindingen tot stand komen, ook al is er nog CPU-capaciteit beschikbaar. Wie met grote keepalive-pools werkt, heeft voldoende descriptoren en event-slots per worker nodig. Een goede inleiding hierover is te vinden in \u201e<a href=\"https:\/\/webhosting.de\/nl\/nginx-worker-verbindingen-schaalbaarheid-duizenden-verzoeken-trafficboost\/\">Worker-Connections opschalen<\/a>\u201c, waarin de verbanden tussen gebeurtenissen, verbindingen en belasting worden toegelicht. Doordachte instellingen zorgen ervoor dat hergebruik bij inactiviteit en het tot stand brengen van nieuwe verbindingen naast elkaar kunnen plaatsvinden.<\/p>\n\n<pre><code>worker_processes auto;\n\nevents {\n    worker_connections 4096;\n    # Optioneel: reuseport kan de verdeling op kernelniveau verbeteren\n    # multi_accept on;\n}\n\nhttp {\n    keepalive_timeout 60s;\n    keepalive_requests 200;\n\n upstream backend {\n server 127.0.0.1:9000;\n keepalive 64;\n    }\n}\n<\/code><\/pre>\n\n<h2>Optimalisatie van het besturingssysteem en de sockets<\/h2>\n\n<p>Ik controleer de systeemlimieten, zodat Keepalive zijn potentieel ten volle kan benutten. Te weinig descriptoren of overvolle socket-wachtrijen leiden tot <strong>kunstmatige knelpunten<\/strong>. Naast `ulimit` en `worker_rlimit_nofile` zijn kernelbeperkingen van cruciaal belang.<\/p>\n\n<pre><code># Voorbeeldwaarden voor sysctl (met de nodige voorzichtigheid aanpassen en testen)\nfs.file-max = 1000000\nnet.core.somaxconn = 65535\nnet.core.netdev_max_backlog = 16384\nnet.ipv4.ip_local_port_range = 1024 65000\nnet.ipv4.tcp_fin_timeout = 15\nnet.ipv4.tcp_tw_reuse = 1\nnet.ipv4.tcp_max_syn_backlog = 262144\n<\/code><\/pre>\n\n<p>Ik stem deze waarden af op de omgeving: veel kortstondige verbindingen hebben baat bij een breed poortbereik en korte FIN-\/TIME_WAIT-tijden. Bij upstream-keepalive verminder ik <em>Neuconnects<\/em>, waardoor de TIME_WAIT-drukken afnemen. Daarnaast houd ik rekening met <strong>NAT<\/strong>-Apparaten tussen de proxy en de backend: te strenge time-outs bij inactiviteit in het netwerk zorgen ervoor dat verbindingen op onvoorspelbare momenten worden verbroken. Een gematigde limiet voor het aantal verzoeken per socket en TCP-keepalives (<code>proxy_socket_keepalive on;<\/code>) voorkomen dat verbindingen \u201everouderd\u201c raken.<\/p>\n\n<h2>De header en HTTP-versie correct instellen<\/h2>\n\n<p>Ik let op <strong>HTTP\/1.1<\/strong> naar de backend, omdat Upstream-Keepalive alleen daarmee werkt. Daarnaast schakel ik actieve verbindingsbeheer via headers uit, zodat NGINX de persistentie zelfstandig beheert. Aan de clientzijde laat ik Keep-Alive volgens de standaard werken en beperk ik de levensduur via time-out en verzoeklimiet. Daarnaast controleer ik de idle-time-outs van de backend en stel ik deze iets hoger in dan bij NGINX om resetfouten te voorkomen. Schone headers zorgen voor de <strong>Hergebruik<\/strong> zonder ongewenste sluitingen.<\/p>\n\n<pre><code># Voorbeeld: proxy-locatie met correcte headers\nlocation \/api\/ {\n    proxy_pass http:\/\/backend;\n    proxy_http_version 1.1;\n    proxy_set_header Connection \"\";\n}\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-keepalive-optimization-7123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Verschil: HTTP Keep-Alive versus TCP Keep-Alive<\/h2>\n\n<p>Ik maak een strikt onderscheid tussen <strong>HTTP Keep-Alive<\/strong> (meerdere HTTP-verzoeken per verbinding) en <strong>TCP-Keepalive<\/strong> (Tests op besturingssysteemniveau om inactieve verbindingen te detecteren). HTTP Keep-Alive regel ik met <code>keepalive_timeout<\/code> en <code>keepalive_requests<\/code>, terwijl TCP-keepalives, afhankelijk van de stack, via <code>proxy_socket_keepalive on;<\/code> en systeemparameters draaien. Voor backends die via onstabiele netwerken werken, schakel ik TCP-keepalives in om vastgelopen sockets sneller op te ruimen.<\/p>\n\n<h2>Langlopers en speciale gevallen: WebSockets, SSE, gRPC<\/h2>\n\n<p>WebSockets en servergebeurtenissen zijn <strong>Langlaufer<\/strong>, die een verbinding gedurende lange tijd openhouden \u2013 hier speelt klassieke Reuse een ondergeschikte rol. Ik zorg voor geschikte <code>proxy_read_timeout<\/code> en bescherm mij met <code>send_timeout<\/code> tegen <em>Slowloris<\/em>-effecten. Voor gRPC (op basis van HTTP\/2) gelden de overwegingen met betrekking tot multiplexing; ik stel de time-outs voor inactiviteit zo in dat streams niet onnodig worden afgesloten.<\/p>\n\n<pre><code>location \/ws\/ {\n    proxy_pass http:\/\/backend;\n    proxy_http_version 1.1;\n    proxy_set_header Upgrade $http_upgrade;\n    proxy_set_header Connection \"upgrade\";\n    proxy_read_timeout 300s;\n    send_timeout 30s;\n}\n<\/code><\/pre>\n\n<h2>Bewaking en statistieken<\/h2>\n\n<p>Ik meet het succes aan de hand van kengetallen zoals het percentage nieuwe upstream-verbindingen, <strong>stroomopwaartse_verbindingstijd<\/strong> en het aandeel open verbindingen per worker. Dalende connect-rates bij een gelijkblijvend of stijgend aantal verzoeken duiden op succesvol hergebruik. Opvallende time-outs of het opnieuw tot stand brengen van verbindingen wijzen op tegenstrijdige time-outs tussen NGINX en de backend. Daarnaast houd ik het geheugen, de bestandsdescriptoren en de event-queues onder belasting in de gaten. Wie dit regelmatig controleert, ontdekt trends in een vroeg stadium en voorkomt dure <strong>Storingen<\/strong>.<\/p>\n\n<h2>Verbeteringen in de logboekregistratie voor meer transparantie bij hergebruik<\/h2>\n\n<p>Om meer inzicht te krijgen, voeg ik verbindingsgegevens toe aan het toegangslogboek. Zo kan ik zien hoe vaak een TCP-verbinding wordt hergebruikt en hoe de verbindingstijden zich ontwikkelen.<\/p>\n\n<pre><code>log_format keepalive_fmt\n  '$remote_addr $host \"$request\" $status $body_bytes_sent '\n  '$request_time $upstream_connect_time '\n  'conn:$connection reqs:$connection_requests';\n\naccess_log \/var\/log\/nginx\/access_keepalive.log keepalive_fmt;\n<\/code><\/pre>\n\n<p>Ik bekijk de mediaan- en P95\/P99-waarden van <em>stroomopwaartse_verbindingstijd<\/em> en de verdeling van <em>$-verbindingsverzoeken<\/em>. Stijgende Reuse-waarden bij een stabiele latentie betekenen dat de pools en time-outs goed zijn ingesteld.<\/p>\n\n<h2>Typische struikelblokken en oplossingen<\/h2>\n\n<p>Te grote pools vullen de verbindingsslots op, terwijl nieuwe clients moeten wachten; daarom houd ik de grootte gematigd en pas ik deze aan. Verschillende time-outs voor inactiviteit tussen de proxy en de backend leiden tot resets, dus stel ik de backend net iets hoger in dan <strong>NGINX<\/strong>. Een vergeten \u201eConnection: close\u201c in de proxy-header onderbreekt de persistentie, daarom maak ik de header consequent leeg. TLS-onderhandeling kan bij veel nieuwe verbindingen de CPU belasten, wat ik verzacht door een hoger hergebruikspercentage. Bij sporadische netwerkstoringen helpt een gematigde verzoeklimiet per socket, zodat oude <strong>Sessies<\/strong> niet eeuwig leven.<\/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\/09\/nginx_keepalive_optimierung_4723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praktijkgerichte configuraties<\/h2>\n\n<p>Voor drukbezochte websites kies ik een korte time-out en een gemiddeld hoge verzoeklimiet, zodat assets effici\u00ebnt werken. Bij API\u2019s met terugkerende oproepen verhoog ik de limiet om het aantal TCP- en TLS-handshakes verder te verminderen. Ik dimensioner upstream-pools op basis van de verwachte parallelliteit en test deze met realistisch verkeer. Elke omgeving gedraagt zich anders, daarom controleer ik na wijzigingen de latentie en foutpatronen. Twee voorbeelden illustreren dit <strong>Startwaarden<\/strong>, die ik vervolgens met statistieken verfijn.<\/p>\n\n<pre><code># Scenario 1: Drukbezochte website\nhttp {\n    keepalive_timeout 30s;\n    keepalive_requests 300;\n\n upstream app {\n server 127.0.0.1:8080;\n        keepalive 32;\n    }\n\n server {\n listen 443 ssl http2;\n # HTTP\/2-idle in de gaten houden\n http2_idle_timeout 45s;\n    }\n}\n<\/code><\/pre>\n\n<pre><code># Scenario 2: API met periodieke aanroepen\nhttp {\n    keepalive_timeout 75s;\n    keepalive_requests 1000;\n\n    upstream api_backend {\n server 127.0.0.1:9001;\n keepalive 64;\n    }\n\n    server {\n listen 443 ssl http2;\n # Iets langer idle-venster voor terugkerende verzoeken\n http2_idle_timeout 75s;\n    }\n}\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\/09\/serverraum-nginx-3721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Checklist voor iteratieve optimalisatie<\/h2>\n\n<p>Ik begin met een analyse van de huidige situatie: verkeerspatronen, responstijden en foutpercentages bepalen het tempo. Vervolgens stel ik de client-time-out en het aantal verzoeken per gebruiker in op solide startwaarden en activeer ik de upstream-pools. De backend-idle-time-outs stel ik iets hoger in dan bij NGINX, zodat er geen onverwachte <strong>Resets<\/strong> voorkomen. Vervolgens houd ik de verbindingssnelheden, de connect-tijd en het aantal open sockets per worker in de gaten. Wie zich verder wil verdiepen in de mate van hergebruik, vindt hier suggesties over <a href=\"https:\/\/webhosting.de\/nl\/http-verbinding-hergebruik-keepalive-optimalisatie-serverperf-boost\/\">Aansluiting Hergebruik<\/a> en redelijke bovengrenzen.<\/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\/09\/nginx_keepalive_opt_5731.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Aanvullende diagnose: mismatches en tijdsgedrag<\/h2>\n\n<p>Als verbindingen schijnbaar \u201ezonder reden\u201c worden verbroken, ga ik op zoek naar <strong>Mismatches<\/strong> in de keten: Client-Idle versus NGINX-time-out versus Backend-Idle en tussenliggende NAT\/gateways. Ik verhoog de backend-time-out iets boven de NGINX-waarde, controleer de resetcodes in het foutenlogboek en kijk of <em>stroomopwaartse_verbindingstijd<\/em> pieken vertoont. Vaak volstaat een kleine buffer (bijv. +10\u201320%) bij de backend-time-out om resets te voorkomen.<\/p>\n<p>Ik merk bovendien op dat \u201e<em>langdurige omhelzing<\/em>\u201c-Fasen: Bij het sluiten laat NGINX inkomende gegevens kort doorlopen, wat worker-bronnen in beslag neemt. Een groot aantal gelijktijdige sluitingen kan events blokkeren. In dergelijke gevallen pas ik de sluitingsvensters aan en houd ik het totale aantal open verbindingen in evenwicht door zinvolle keepalive-waarden in te stellen.<\/p>\n\n<h2>Samenvatting: Keepalive als middel om de prestaties te verbeteren<\/h2>\n\n<p>Ik maak doelgericht gebruik van Keepalive, omdat het de kosten voor het opbouwen van verbindingen verlaagt, de latentie vermindert en de CPU ontlast. De combinatie van een geschikte time-out, een strakke limiet voor verzoeken en geschikte upstream-pools levert merkbare <strong>Snelheid<\/strong>. Zonder monitoring blijft potentieel onbenut; daarom controleer ik de kengetallen voortdurend en pas ik de waarden stap voor stap aan. Wie extra reserves nodig heeft, let op het aantal workers, de verbindingsslots en de juiste verwerking van headers. Professionele configuraties, bijvoorbeeld bij <strong>webhoster.de<\/strong>, maken optimaal gebruik van deze mogelijkheden en leveren snelle, betrouwbare diensten.<\/p>","protected":false},"excerpt":{"rendered":"<p>Leer hoe je NGINX Keepalive-verzoeken kunt optimaliseren om de prestaties van je webservers aanzienlijk te verbeteren. Met praktische instellingen voor keepalive_timeout, keepalive_requests, upstream-keepalive en worker-tuning \u2013 inclusief aandacht voor NGINX Keepalive als centrale instellingsfactor.<\/p>","protected":false},"author":1,"featured_media":21452,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-21459","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":"112","_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 keepalive","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":"21452","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21459","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/comments?post=21459"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21459\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/21452"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=21459"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=21459"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=21459"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}