HTTP-verzoeken kunnen blokkeren, ook al lijken CPU, RAM en bandbreedte open te zijn, omdat onzichtbare limieten, filters en wachtrijen in de hele keten van kracht zijn. Ik leg uit waar Grenzen hoe ze werken en welke instellingen ik instel zodat aanvragen weer soepel verlopen.
Centrale punten
Voordat ik in detail ga, zal ik de belangrijkste oorzaken samenvatten en benoemen waar ik als eerste naar kijk. Deze punten hebben betrekking op de typische knelpunten die leiden tot congestie ondanks vrije middelen. Ik heb de lijst met opzet compact gehouden, zodat je meteen de beginpunten kunt controleren. Het belangrijkste punt is dat elke laag zijn eigen regels heeft die onafhankelijk van CPU en RAM van toepassing zijn. Als je deze regels kent, kun je veel „onverklaarbare“ wachttijden snel oplossen.
- Grenzen voor werknemersTe weinig processen/threads blokkeren nieuwe verbindingen ondanks vrije CPU.
- BeveiligingslaagWAF/webfilters blokkeren patronen, methoden of clients, vaak zonder hoge belasting.
- ConcurrentiePHP-FPM, database en proxies beperken gelijktijdige sessies.
- Keep-Alive/TimeoutsLange verbindingen houden slots bezet, aanvragen komen in wachtrijen terecht.
- Filter voor de klantBrowserextensies houden verzoeken tegen voordat ze de server bereiken.
Deze kernpunten zijn vaak voldoende om gedrag gericht te controleren. In het volgende zal ik laten zien hoe ik hieruit specifieke maatregelen afleid en Verstoppingen schoon.
Waarom HTTP-verzoeken blokkeren ondanks vrije bronnen
Een verzoek passeert verschillende lagen: Client, netwerk, filter, webserver, runtime-omgeving en database. Elke laag brengt zijn eigen Grenzen die van kracht worden ongeacht CPU, RAM of bandbreedte. Als werkerslots bezet zijn of regels actief zijn, wacht het verzoek in een wachtrij of wordt het onmiddellijk geannuleerd. Deze wachttijd verschijnt vaak helemaal niet in klassieke resource diagrammen. Dit is precies wat leidt tot de misvatting dat de server „leeg“ is, ook al worden verzoeken niet beantwoord.
Beveiligingslaag: WAF, filters en providerregels
Veel blokkades treden op nog voordat de applicatie draait. Firewalls voor webtoepassingen, IDS/IPS en filters aan de providerzijde herkennen patronen en vertragen of blokkeren deze [1][5][9]. Verdachte parameters, oude protocollen of combinaties van methoden zijn genoeg om een Slot om te ontsteken. Vanuit het oogpunt van de operator lijkt dit op een serverfout, maar de beslissing wordt „stroomopwaarts“ genomen. Ik controleer daarom de WAF logs en noteer de request ID, IP, tijd en statuscode. Met deze gegevens kan de regel worden geïdentificeerd en gericht worden aangepast zonder de beveiliging in gevaar te brengen.
Clientzijde: browserextensies en lokale blokkers
Niet elk verzoek bereikt de server. Adblockers, wachtwoordmanagers en scriptblokkers houden URL's al tegen in de browser; de DevTools tonen dan „Requests to the Server Have Been Blocked by an Extension“ [3][7]. Ik test in een privévenster, deactiveer extensies en controleer of de Verzoek überhaupt is verzonden. Het helpt ook om prioriteiten in de frontend te regelen, bijvoorbeeld met een schone Prioritering van verzoeken voor kritieke bedrijfsmiddelen. Dit voorkomt dat niet-kritische oproepen van derden belangrijke routes vertragen.
Methode en routing begrijpen: 405, 403, 429
Een 405 „Method Not Allowed“ geeft duidelijk aan dat de server de bron herkent, maar de gebruikte methode niet toestaat [5]. Op dezelfde manier duiden 403 op filters of rechten en 429 op actieve snelheidsbeperking. In logboeken kan ik snel herkennen of een globale regel methoden toestaat zoals PUT of DELETE of dat een eindpunt nooit is geïmplementeerd. Vervolgens pas ik de routing, controller of WAF-regel aan. Op deze manier lost vermeende „blokkering“ op in een schone correctie van methoden en paden.
Webserverarchitectuur en limieten voor werkers
Apache, NGINX, LiteSpeed en OpenLiteSpeed behandelen verbindingen verschillend [4]. De beslissende factoren zijn het aantal worker processen, threads en hoe keep-alive sockets slots bezetten. Als alle workers bezet zijn door lange verbindingen, gaan nieuwe verzoeken naar een Wachtrij, hoewel de CPU en RAM vrij lijken. Daarom analyseer ik verbindingsstatussen en pas ik workers, backlogs en keep-alive tijden aan. Achtergrondkennis van wachtrijen helpt, bijvoorbeeld bij het onderwerp Serverwachtrij en latentie.
| laag | Relevante limiet | Typisch symptoom | Diagnostische aantekening |
|---|---|---|---|
| webserver | Aantal werkers/thread | Wachtrijen, 503 onder belasting | Statusmodules, verbindingsstatussen controleren |
| PHP-FPM/FastCGI | max_kinderen / pm | Hangende verzoeken, hoge time-to-first-byte | FPM-logboeken, traag logboek, aantal processen |
| Database | max_verbindingen | Fout „Te veel verbindingen“.“ | SHOW PROCESSLIST, Verbinding pieken |
| WAF/Filter | Handtekeningen, methoden | 403/405, gebroken formulierberichten | WAF logs, regel hit ID's |
| Laadbalancer | Per-Backend-Conn-Limit | Inconsistente responstijden | LB-Stats, Backend-Gezondheid |
Concurrency in PHP-FPM, database en proxies
Gelijktijdige verwerking barst vaak het eerst los in de runtime-omgeving. Als alle PHP FPM-werkers bezig zijn, is er geen slot beschikbaar voor nieuwe scripts; de verzoeken wachten, hoewel de CPU werkt nauwelijks. De situatie is vergelijkbaar voor databases met max_connections of voor proxies met verbindingslimieten per backend. Ik optimaliseer eerst de duur van individuele verzoeken voordat ik de limieten verhoog. Op deze manier verkort ik de documenttijd per slot en verklein ik de kans dat wachtrijen groeien.
Trage backends en PHP-sessievergrendeling
Lange database queries, externe API's of bestands-I/O houden werkers aanzienlijk langer bezig. Session locking kan ook hele ketens vertragen, zoals WordPress logins of winkelwagentjes. Ik controleer of parallelle verzoeken naar dezelfde sessie-ID na elkaar worden uitgevoerd in plaats van tegelijkertijd. Als dat zo is, vertrouw ik op gerichte ontgrendeling, beperk ik kritieke schrijftoegang en volg ik beproefde instructies op de PHP sessie vergrendeling. Hierdoor kan ik sneller slots vrijmaken en Wachttijden merkbaar.
Time-outs, keep-alive en verbindingsstrategieën
Keep-alive tijden die te lang zijn verbruiken bronnen, terwijl die te kort zijn handshakes en latency veroorzaken. Ik kies waarden die overeenkomen met het verkeersprofiel en stel limieten in voor header, body en backend timeouts. Het is belangrijk om timeouts niet alleen op de webserver maar gestandaardiseerd langs de keten: proxy, app, database. Daarnaast voorkom ik idle blocking door fijnere HTTP/2/HTTP/3-instellingen en prioritering. Hierdoor blijven slots beschikbaar zonder dat clients steeds opnieuw verbinding moeten maken.
Hostingmodellen: Gedeeld, VPS, Dedicated
Shared hosting stelt vroege filters en harde quota's in zodat het platform eerlijk blijft [1]. Op VPS isoleren providers CPU en RAM, maar handhaven ze limieten voor I/O, netwerk of beveiliging; de verschillen in prestaties en monitoring zijn duidelijk [10]. Op dedicated servers draag ik de volledige verantwoordelijkheid voor de webserver, database en WAF-configuratie. Vergelijkingen laten zien dat moderne stacks met HTTP/3, NVMe en DDoS-bescherming duidelijke voordelen bieden [2][6][11][8]. Wie veel parallellisme nodig heeft, heeft baat bij duidelijk gedocumenteerde Grenzen en ondersteuning, wat helpt met regelunits.
Systematische analyse: stap voor stap
Ik begin bij de bron: verzendt DevTools het verzoek echt, of wordt het geblokkeerd door een extensie [3][7]? Dan kijk ik naar statuscodes: 403/405/429/503 geven sterke aanwijzingen voor filters, methoden of capaciteit [5]. Tegelijkertijd controleer ik logs van de webserver, app en WAF om patronen en terugkerende handtekeningen te vinden [1][9]. Vervolgens controleer ik het aantal werkers, FPM-parameters, keep-alive en databaseverbindingen en verhoog ik limieten op testbasis met meetpunten ervoor en erna. Tot slot simuleer ik belasting, observeer knelpunten in realtime en controleer of de Wachtrijen krimpen.
Beste praktijken tegen blokkades
Ik formuleer concurrency targets per laag en stel limieten in zodat belastingspieken worden opgevangen. De webserver moet passen bij het verkeerspatroon; benchmarks helpen bij de selectie en configuratie [4]. Ik optimaliseer backends eerst logisch: snellere queries, kortere transacties, minder seriële secties. Ik houd de beveiligingsregels streng genoeg tegen aanvallen, maar met uitzonderingen voor legitieme aanvallen Voorbeeld. Monitoring houdt niet op bij CPU/RAM: ik kijk naar verbindingen, wachtrijen, responstijden en foutcodes zodat knelpunten zichtbaar blijven [6][11].
Praktijknotities: aanvragen blokkeren hosting
In gedeelde omgevingen komen blokkades vaak eerder terecht dan de daadwerkelijke webruimte; ondersteuning heeft dan specifieke verzoekgegevens nodig om regels aan te passen [1]. Op VPS schaal ik geleidelijk: meer werkers, geschiktere keep-alive waarden en nauwlettender toezicht op de database [10]. Op mijn eigen hardware beslis ik over load balancing, WAF regels en limieten per backend. Projecten met zeer parallelle toegang hebben baat bij een schone HTTP/2/HTTP/3 configuratie en duidelijke reserves voor Tips. Als je groei verwacht, plan dan om al vroeg over te schakelen op krachtigere tarieven en bespaar later een hoop tuning moeite [2][6][10][11].
Netwerk- en kernellimieten: achterstand, poorten en descriptors
Naast de webserver en de app beperkt de kernel het aantal verbindingen dat tegelijkertijd kan binnenkomen, tot stand kan worden gebracht en kan worden beheerd. Ik controleer eerst de Lijst achterstandZelfs als de webserver veel werkers heeft, kan de acceptwachtrij kort zijn. De interactie tussen de applicatie (listen backlog), kernel (somaxconn) en SYN backlog (tcp_max_syn_backlog) bepaalt of verbindingen in de wachtrij blijven of worden weggegooid. Symptomen zijn toenemende connectietijden en retransmissies - met een laag CPU-gebruik. Ik vergelijk de waarden en meet het werkelijke gebruik van de wachtrijen om drops te voorkomen.
Een andere klassieker is de conntrack tafel voor NAT/firewall opstellingen. Als het vol is, verdwijnen verbindingen „zonder een spoor“; de applicatie ziet nooit een verzoek. Ik herken dit aan meldingen in het systeemlogboek en plotselinge timeouts tijdens piekbelastingen. Tegenmaatregelen zijn: geschikte tabelgrootte, realistische idle timeouts voor protocollen, minder onnodige NAT-paden en efficiënte keep-alives die verbindingen verstandig hergebruiken.
Ik controleer ook het aantal open Bestandsdescriptors (ulimit -n). Als veel gelijktijdige sockets en bestanden de beperkende limieten bereiken, mislukt Accept („te veel open bestanden“) en stapelen nieuwe aanvragen zich op. De oplossing is meestal triviaal: stel de nofile limieten voor de webserver, proxy en database in op een gezond niveau - en maak ze persistent, niet alleen interactief.
In sterk parallelle opstellingen observeer ik de Tijdelijk poortbereik en TIME_WAIT-poorten. Vooral achter NAT-gateways raken de beschikbare bronpoorten uitgeput als er massaal korte verbindingen worden opgezet. Ik vertrouw daarom op hergebruik van verbindingen (keep-alive, HTTP/2/3), verminder onnodige kortstondige verbindingen en stem de TIME_WAIT afhandeling zorgvuldig af zonder de stabiliteit in gevaar te brengen. Het resultaat: minder poortuitputting en stabielere verbindingstijden onder belasting.
Op de netwerkkaart controleer ik wachtrellengtes, offloading-instellingen en IRQ-distributie. Ongelijk verdeelde interrupts of overbelaste wachtrijen genereren latency pieken die niet merkbaar zijn in applicatielogs. Met gebalanceerde IRQ-balancering en verstandige Qdisc-instellingen (sleutelwoord Bufferbloat) Ik verlaag de latentie zonder de bandbreedte te beperken.
HTTP/2 en HTTP/3: multiplexing correct gebruiken
Multiplexing lost veel problemen op, maar brengt ook nieuwe beperkingen met zich mee: Maximale stroomnummers, flow control window en idle timeouts gelden per verbinding. Als de waarde voor gelijktijdige streams te laag is, „hangen“ nieuwe verzoeken, ook al is de TCP of QUIC verbinding tot stand gebracht. Ik controleer daarom hoeveel kritieke bronnen parallel geladen moeten worden en pas de streamlimieten zorgvuldig aan. Tegelijkertijd let ik op redelijke Stroomregeling-window zodat grote reacties niet worden gesmoord.
HTTP/2 multiplexer over TCP kan last hebben van head-of-line blokkering bij pakketverlies; HTTP/3 op QUIC vermijdt dit, maar vereist schone TLS/ALPN instellingen en stabiele padbehandelingsregels. Ik test beide paden en selecteer de protocollen die overeenkomen met het verkeersprofiel. Belangrijk: Vertrouw niet blindelings op prioritering - browsers en servers interpreteren het verschillend. Ik concentreer me op kritieke routes en controleer of prioriteiten echt werken en of slots niet worden ingenomen door langlopende secundaire stromen.
CORS, preflights en header/body-limieten
Niet elke 4xx-fout komt van de server. CORS-overtredingen optreden in de browser en verschijnen in de console, niet in het toegangslogboek. Ik controleer of preflight verzoeken (OPTIONS) correct worden beantwoord en of WAF/proxies deze methode toestaan. Als headers zoals Access-Control-Allow-Methods/-Headers ontbreken, „blokkeert“ de browser het antwoord - zonder serverbelasting.
Nog een knelpunt: Kop- en cookiematen. Overvolle cookies, veel Vary headers of grote verwijzingsregels leiden tot 431 fouten of stille drops door bufferlimieten. Ik beperk de cookie-ballast, consolideer headers en stel buffergroottes consistent in langs de keten. Voor uploads let ik op bodylimieten, 100-continu afhandeling en consistente Chunked codering-Ondersteuning voor alle proxies. Als de body- en uploadlimieten niet overeenkomen, wachten clients op een vrijgave die nooit komt - verzoeken lijken te „hangen“.
DNS en TLS: handshakes als verborgen latentie
DNS-omzetting en TLS-onderhandeling zijn vaak blinde vlekken. Meerdere CNAME-ketens, langzame resolvers of een IPv6/IPv4 mismatch verlengen de starttijd zonder CPU te gebruiken. Ik verminder onnodige DNS-sprongen, stel verstandige TTL's in en zorg voor snelle resolverpaden. Aan de TLS kant controleer ik certificaatketens, geactiveerde cipher suites, OCSP stapling en sessie hervatting. Een schone ALPN handdruk voorkomt downgrades naar HTTP/1.1, die een grotere druk leggen op keep-alive slots. Resultaat: kortere time-to-first-byte en stabieler parallellisme, vooral op mobiele netwerken.
CDN/Edge: Caching, snelheidslimieten en IP-reputatie
Tussen client en origin beslissen CDN's, reverse proxies en DDoS-beveiligingssystemen over Duiker en throttle. Ik controleer of kritieke routes correct worden gecachet (stale-while-revalidate, stale-if-error) en of negatieve caches fouten langer vasthouden dan nodig is. Snelheidslimieten, botbeheer en IP-reputatie kunnen legitiem verkeer temperen, vooral bij gedeelde netwerken of zware API-toegang. Ik segmenteer verkeer (bijv. API vs. assets), definieer clear cache keys en schakel regels selectief uit voor vertrouwde clients. Dit ontlast Origin en voorkomt dat CDN wachtrijen groeien terwijl de server er „onderbezet“ uitziet.
Containers en orkestratie: cgroups, Ingress en conntrack
In containers aanbrengen cgroep limieten voor CPU, RAM, pids en bestanden. Een te krap CPU-quotum leidt tot throttling: processen wachten op CPU-tijd ook al is de host vrij. Ik controleer quota en zorg ervoor dat ingress/proxy pods genoeg bestandsdescriptors en buffers hebben. In Kubernetes controleer ik ingress timeouts, readiness/liveness probes en service-implementaties (IPVS), omdat defecte probes of timeouts zigzag latentie en onnodige herstarts veroorzaken.
Een vaak over het hoofd gezien knelpunt is de NAT/conntrack-capaciteit per knooppunt. Veel kortstondige verbindingen (bijv. egress naar externe API's) vullen de conntrack tabel, waarna verzoeken „verdwijnen“ in het netwerk. Ik schaal de tabel, stel realistische timeouts in en bundel externe verzoeken zodat er minder nieuwe verbindingen worden gemaakt. Ik plan PodDisruptionBudgets, rolling updates en HPA-schaling zodanig dat er op piekmomenten geen capaciteit aan de planner wordt onttrokken. theoretisch genoeg arbeiders zou hebben.
Waarneembaarheid: correlatie, tracering en zinvolle metriek
Om verstoppingen snel te vinden, heb ik het volgende nodig Continue correlatie. Ik wijs verzoek-ID's (bijv. traceparent) toe aan de edge, webserver, app en database en schrijf ze naar de logboeken. Hierdoor kan ik zien of een verzoek faalt bij de WAF, wacht bij de webserver, vastzit in de FPM wachtrij of geblokkeerd is in de database. Ik werk met Histogrammen in plaats van puur gemiddelde waarden en monitor P95/P99 latency, open verbindingen, acceptwachtrij, FPM wachtrijlengte, actieve DB sessies en backend foutcodes. Ik gebruik ook synthetische controles om de effecten aan de clientkant duidelijk te scheiden van de effecten aan de serverkant.
Voor afwijkingen gebruik ik een Drilldown-De procedure: eerst edge/WAF logs, dan loadbalancer, dan webserver toegang/fout, dan app en FPM logs en tenslotte DB en systeem logs. Dit pad laat me precies zien waar de tijd verloren gaat en bij welke grens het verzoek stopt. Met gerichte metrics per laag vermijd ik onderbuikgevoelens en verkort ik drastisch de tijd naar de hoofdoorzaak.
Draaiboek en checklist voor tuning
In de praktijk heb ik een compact draaiboek dat ik aanpas aan de omgeving:
- ReproduceerbaarheidNagel het scenario vast (route, methode, grootte, client), log tijdstempel en ID's.
- Controleer laag voor laagBrowser/Extensies, CORS/Preflight, WAF-Hits, LB-Stats, Webserver-Status, FPM-Queue, DB-Active/Locks.
- Wachtrijen zichtbaar makenAccept/SYN achterstand, FPM luisterwachtrij, proxy achterstand, DB verbindingspool.
- Limieten synchroniserenWorker/threads, somaxconn, nofile, max_connections, streamlimieten voor H2/H3, body/header-limieten, timeouts.
- De bezettingstijd verkortenVersnel query's, vermijd sessiesloten, verminder I/O, comprimeer reacties en cache ze op een verstandige manier.
- Strategieën harmoniserenKeep-Alive-duur, HTTP/2/3-parametrisering, prioritering van kritieke routes.
- Beveiliging aanpassenGerichte uitsluiting van WAF-regels in plaats van globale verzwakking; logboekregistratie met hit-ID's.
- SchalenBepaal gelijktijdigheid per dienst, voer belastingstests uit, meet reserves, verhoog limieten alleen na optimalisatie.
- TegenvallersStroomonderbreker voor langzame backends, retry-beleid met jitter, „stale-if-error“ voor kritieke bedrijfsmiddelen.
Kort samengevat
Geblokkeerde verzoeken met vrije CPU en RAM worden meestal veroorzaakt door limieten, filters en verbindingsstrategieën - niet door een gebrek aan prestaties. Ik controleer eerst waar het verzoek stopt: browser, WAF, webserver, runtime of database. Vervolgens minimaliseer ik de bezettingstijden per slot, verwijder ik onnodige Sloten en stel realistische time-outs in. Ik houd de beveiliging hoog, pas regels aan tegen vals alarm en verzamel bewijs in logboeken. Met deze aanpak blijven HTTP-verzoeken betrouwbaar toegankelijk, zelfs wanneer het verkeer piekt en elke seconde telt.
