Varför HTTP-förfrågningar kan blockeras trots att det finns tillräckligt med resurser tillgängliga

HTTP-förfrågningar kan blockeras även om CPU, RAM och bandbredd verkar öppna eftersom osynliga gränser, filter och köer träder i kraft längs hela kedjan. Jag förklarar var Gränser hur de fungerar och vilka inställningar jag gör för att förfrågningar ska gå smidigt igen.

Centrala punkter

Innan jag går in i detalj ska jag sammanfatta de viktigaste orsakerna och nämna vad jag tittar på först. Dessa punkter täcker de typiska flaskhalsarna som leder till överbelastning trots fria resurser. Jag har medvetet hållit listan kompakt så att du omedelbart kan kontrollera utgångspunkterna. Det viktiga är att varje lager har sina egna regler som gäller oberoende av CPU och RAM. Om du känner till dessa regler kan du snabbt lösa många „oförklarliga“ väntetider.

• Gränser för arbetstagareFör få processer/threads blockerar nya anslutningar trots ledig CPU.
• SäkerhetsskiktWAF/webbfilter blockerar mönster, metoder eller klienter, ofta utan hög belastning.
• SamtidighetPHP-FPM, databas och proxyservrar begränsar samtidiga sessioner.
• Keep-Alive/TimeoutsLånga förbindelser tar tid, förfrågningar hamnar i kö.
• Filter för klienterWebbläsartillägg stoppar förfrågningar innan de når servern.

Dessa nyckelpunkter är ofta tillräckliga för att kontrollera beteendet på ett målinriktat sätt. I det följande kommer jag att visa dig hur jag härleder specifika åtgärder från detta och Blockeringar rent.

Varför HTTP-förfrågningar blockeras trots lediga resurser

En förfrågan passerar genom flera lager: Klient, nätverk, filter, webbserver, runtime-miljö och databas. Varje lager medför sina egna Gränser som träder i kraft oavsett CPU, RAM eller bandbredd. Om arbetsplatserna är upptagna eller reglerna är aktiva, väntar förfrågan i en kö eller avbryts omedelbart. Denna väntetid syns ofta inte alls i klassiska resursdiagram. Det är just detta som leder till missuppfattningen att servern är „tom“, trots att förfrågningar inte besvaras.

Säkerhetslager: WAF, filter och regler för leverantörer

Många blockeringar inträffar innan applikationen ens är igång. Brandväggar för webbapplikationer, IDS/IPS och filter på leverantörssidan känner igen mönster och saktar ner eller blockerar dem [1][5][9]. Misstänkta parametrar, gamla protokoll eller kombinationer av metoder räcker för att orsaka en Lås att antändas. Ur operatörens synvinkel ser det här ut som ett serverfel, men beslutet fattas „uppströms“. Jag kontrollerar därför WAF-loggarna och noterar request-ID, IP, tid och statuskod. Med hjälp av dessa uppgifter kan regeln identifieras och justeras på ett målinriktat sätt utan att säkerheten äventyras.

Klientsidan: webbläsartillägg och lokala blockerare

Inte alla förfrågningar når servern. Annonsblockerare, lösenordshanterare och skriptblockerare stoppar redan webbadresser i webbläsaren; DevTools visar då „Förfrågningar till servern har blockerats av ett tillägg“ [3][7]. Jag testar i ett privat fönster, avaktiverar tillägg och kontrollerar om Begäran skickades överhuvudtaget. Det hjälper också till att kontrollera prioriteringar i frontend, till exempel med en ren Prioritering av förfrågningar för kritiska tillgångar. Detta förhindrar att icke-kritiska samtal från tredje part försenar viktiga rutter.

Förståelsemetod och routing: 405, 403, 429

En 405 „Method Not Allowed“ visar tydligt att servern känner igen resursen men inte tillåter den metod som används [5]. På samma sätt anger 403 filter eller rättigheter och 429 aktiv hastighetsbegränsning. I loggar kan jag snabbt se om en global regel tillåter metoder som PUT eller DELETE eller om en slutpunkt aldrig har implementerats. Jag justerar sedan routingen, styrenheten eller WAF-regeln. På så sätt löses förmodad „blockering“ upp i en ren korrigering av metoder och vägar.

Webbserverarkitektur och begränsningar för arbetare

Apache, NGINX, LiteSpeed och OpenLiteSpeed hanterar anslutningar på olika sätt [4]. De avgörande faktorerna är antalet arbetsprocesser, trådar och hur keep-alive-sockets upptar slots. Om alla arbetare är upptagna av långa anslutningar flyttas nya förfrågningar till en Kö, trots att CPU och RAM verkar vara lediga. Jag analyserar därför anslutningsstatus och justerar workers, backlogs och keep-alive-tider. Bakgrundskunskap om köer är till hjälp, till exempel när det gäller ämnet Serverköer och fördröjning.

skikt	Relevant gränsvärde	Typiskt symptom	Diagnostisk anmärkning
Webbserver	Antal arbetare/trådar	Köer, 503 under belastning	Statusmoduler, kontrollera anslutningsstatus
PHP-FPM/FastCGI	max_barn / pm	Hängande förfrågningar, hög tid-till-första-byte	FPM-loggar, långsam logg, antal processer
Databas	max_anslutningar	Fel „För många anslutningar“	VISA PROCESSLISTA, Anslutningstoppar
WAF/Filter	Underskrifter, metoder	403/405, trasiga inlägg i formuläret	WAF-loggar, ID för träff på regel
Lastbalanserare	Per-bakstycke-Conn-Limit	Inkonsekventa svarstider	LB-statistik, Backend-hälsa

Samtidighet i PHP-FPM, databas och proxyservrar

Samtidig bearbetning spricker ofta först i runtime-miljön. Om alla PHP FPM-arbetare är upptagna finns det ingen ledig plats för nya skript; förfrågningarna väntar även om CPU fungerar knappast. Situationen är liknande för databaser med max_connections eller för proxies med anslutningsgränser per backend. Jag optimerar först varaktigheten för enskilda förfrågningar innan jag höjer gränserna. På så sätt förkortar jag dokumenttiden per slot och minskar sannolikheten för att köerna växer.

Långsamma backends och PHP-sessionslåsning

Långa databasförfrågningar, externa API:er eller fil-I/O binder upp arbetare betydligt längre. Sessionslåsning kan också göra hela kedjor långsammare, t.ex. WordPress-inloggningar eller kundvagnar. Jag kontrollerar om parallella förfrågningar till samma sessions-ID körs i följd istället för samtidigt. Om så är fallet förlitar jag mig på riktad upplåsning, minskar kritiska skrivåtkomster och följer beprövade instruktioner på Låsning av PHP-session. Detta gör att jag kan frigöra platser snabbare och minska Väntetider märkbar.

Timeouts, keep-alive och anslutningsstrategier

För långa keep-alive-tider binder upp resurser, medan för korta genererar handskakningar och fördröjningar. Jag väljer värden som matchar trafikprofilen och sätter gränser för timeouts för header, body och backend. Det är viktigt att ställa in timeouts inte bara på Webbserver men standardiserade längs hela kedjan: proxy, app, databas. Dessutom förhindrar jag blockering i onödan genom finare HTTP/2/HTTP/3-inställningar och prioritering. På så sätt hålls slots tillgängliga utan att klienter ständigt behöver återansluta.

Modeller för värdtjänster: Delad, VPS, Dedikerad

Delad hosting sätter tidiga filter och hårda kvoter så att plattformen förblir rättvis [1]. På VPS isolerar leverantörerna CPU och RAM, men behåller gränser för I/O, nätverk eller säkerhet; skillnaderna i prestanda och övervakning är tydliga [10]. På dedikerade servrar har jag fullt ansvar för webbserver-, databas- och WAF-konfigurationen. Jämförelser visar att moderna stackar med HTTP/3, NVMe och DDoS-skydd ger klara fördelar [2][6][11][8]. De som behöver hög parallellitet drar nytta av tydligt dokumenterade Gränser och support, vilket hjälper till med regelenheter.

Systematisk analys: steg för steg

Jag börjar vid källan: Skickar DevTools verkligen begäran, eller blockeras den av ett tillägg [3][7]? Sedan tittar jag på statuskoder: 403/405/429/503 ger starka indikationer på filter, metoder eller kapacitet [5]. Samtidigt kollar jag loggar från webbserver, app och WAF för att hitta mönster och återkommande signaturer [1][9]. Jag kontrollerar sedan antalet arbetare, FPM-parametrar, keep-alive och databasanslutningar och ökar gränserna på testbasis med mätpunkter före och efter. Slutligen simulerar jag belastning, observerar flaskhalsar i realtid och verifierar att Köer krympa.

Bästa praxis mot blockader

Jag formulerar samtidighetsmål per lager och sätter gränser så att belastningstoppar dämpas. Webbservern måste matcha trafikmönstret; benchmarks hjälper till med urval och konfiguration [4]. Jag optimerar backends logiskt först: snabbare frågor, kortare transaktioner, färre seriella avsnitt. Jag håller säkerhetsreglerna tillräckligt strikta mot attacker, men med undantag för legitima sådana Prov. Övervakningen slutar inte med CPU/RAM: Jag tittar på anslutningar, köer, svarstider och felkoder så att flaskhalsar förblir synliga [6][11].

Övningsanteckningar: blockering av begäran om hosting

I delade miljöer hamnar blockader ofta före det faktiska webbutrymmet; support behöver då specifika förfrågningsdata för att justera reglerna [1]. På VPS skalar jag gradvis: fler arbetare, mer lämpliga keep-alive-värden och närmare övervakning av databasen [10]. På min egen maskinvara beslutar jag om lastbalansering, WAF-regler och gränser per backend. Projekt med mycket parallell åtkomst drar nytta av en ren HTTP/2/HTTP/3-konfiguration och tydliga reserver för Tips. Om du förväntar dig tillväxt, planera att byta till kraftfullare tariffer tidigt och spara en hel del inställningsarbete senare [2][6][10][11].

Begränsningar för nätverk och kernel: backlog, portar och deskriptorer

Förutom webbservern och appen begränsar kärnan hur många anslutningar som kan komma in, upprättas och hanteras samtidigt. Jag kontrollerar först Lista eftersläpning: Även om webbservern har många arbetare kan acceptkön vara kort. Samspelet mellan applikationen (listen backlog), kärnan (somaxconn) och SYN backlog (tcp_max_syn_backlog) avgör om anslutningarna blir kvar i kön eller kasseras. Symptomen är ökande anslutningstider och återsändningar - med lågt CPU-användande. Jag jämför värdena och mäter det faktiska utnyttjandet av köerna för att undvika avbrott.

En annan klassiker är conntrack bord för NAT-/brandväggskonfigurationer. Om den är full försvinner anslutningarna „spårlöst“; applikationen ser aldrig någon förfrågan. Jag känner igen detta genom meddelanden i systemloggen och plötsliga timeouts under toppbelastningar. Motåtgärderna är: lämplig tabellstorlek, realistiska timeouts för inaktiva protokoll, färre onödiga NAT-vägar och effektiva keep-alives som återanvänder anslutningar på ett förnuftigt sätt.

Jag kontrollerar också antalet öppna Filbeskrivningar (ulimit -n). Om många samtidiga socklar och filer når de restriktiva gränserna misslyckas Accept („för många öppna filer“) och nya förfrågningar staplas framför den. Lösningen är vanligtvis trivial: ställ in nofile-gränserna för webbservern, proxyn och databasen på en hälsosam nivå - och gör dem beständiga, inte bara interaktiva.

I starkt parallella uppställningar observerar jag Kortvarigt portintervall och TIME_WAIT-tillstånd. Speciellt bakom NAT-gateways är de tillgängliga källportarna uttömda när korta anslutningar upprättas i massor. Därför förlitar jag mig på återanvändning av anslutningar (keep-alive, HTTP/2/3), minskar onödiga kortlivade anslutningar och ställer in TIME_WAIT-hanteringen noggrant utan att riskera stabiliteten. Resultatet: mindre portutmattning och mer stabila anslutningstider under belastning.

På nätverkskortet kontrollerar jag kölängder, avlastningsinställningar och IRQ-distribution. Ojämnt fördelade avbrott eller överbelastade köer genererar fördröjningstoppar som inte märks i programloggar. Med balanserad IRQ-balansering och förnuftiga Qdisc-inställningar (nyckelord Bufferbloat) Jag minskar fördröjningen utan att begränsa bandbredden.

HTTP/2 och HTTP/3: korrekt användning av multiplexering

Multiplexering löser många problem, men medför nya begränsningar: Maximalt antal strömmar, flödeskontrollfönster och tidsgränser för inaktivitet gäller per anslutning. Om värdet för samtidiga strömmar är för lågt „hänger“ sig nya förfrågningar trots att TCP- eller QUIC-anslutningen är etablerad. Jag kontrollerar därför hur många kritiska resurser som behöver laddas parallellt och justerar noggrant stream-gränserna. Samtidigt är jag uppmärksam på rimliga Flödeskontroll-fönster så att stora svar inte stryps.

HTTP/2 multiplexer över TCP kan drabbas av head-of-line blockering i händelse av paketförlust; HTTP/3 på QUIC undviker detta, men kräver rena TLS/ALPN-inställningar och stabila regler för hantering av sökvägar. Jag testar båda vägarna och väljer de protokoll som matchar trafikprofilen. Viktigt: Lita inte blint på prioriteringen - webbläsare och servrar tolkar den på olika sätt. Jag fokuserar på kritiska vägar och kontrollerar om prioriteringarna verkligen fungerar och om platserna inte tas upp av sekundära strömmar som pågår under lång tid.

CORS, förflygningar och gränser för huvud/kropp

Inte alla 4xx-fel kommer från servern. CORS-överträdelser inträffar i webbläsaren och visas i konsolen, inte i åtkomstloggen. Jag kontrollerar om preflight-förfrågningar (OPTIONS) besvaras korrekt och om WAF/proxies tillåter den här metoden. Om rubriker som Access-Control-Allow-Methods/-Headers saknas „blockerar“ webbläsaren svaret - utan någon serverbelastning.

En annan flaskhals: Header- och cookie-storlekar. Överväxta cookies, många Vary-headers eller stora referer-rader leder till 431-fel eller tysta avbrott på grund av buffertgränser. Jag begränsar cookie-ballast, konsoliderar rubriker och ställer in buffertstorlekar konsekvent längs kedjan. För uppladdningar är jag uppmärksam på kroppsgränser, 100-kontinuerlig hantering och konsekvent Kodning av styckegods-Stöd för alla proxyservrar. Om gränsvärdena för kropp och uppladdning inte stämmer överens väntar klienterna på en release som aldrig kommer - förfrågningar verkar „hänga sig“.

DNS och TLS: Handskakningar som dold latens

DNS-upplösning och TLS-förhandling är ofta blinda fläckar. Flera CNAME-kedjor, långsamma resolvers eller IPv6/IPv4-missmatchning förlänger starttiden utan att använda CPU. Jag minskar onödiga DNS-hopp, ställer in förnuftiga TTL och säkerställer snabba resolver-vägar. På TLS-sidan kontrollerar jag certifikatkedjor, aktiverade chiffersviter, OCSP-häftning och återupptagande av sessioner. En ren ALPN-handskakning förhindrar nedgraderingar till HTTP/1.1, vilket innebär en större belastning på keep-alive-slots. Resultat: kortare tid till första byte och stabilare parallellism, särskilt i mobilnät.

CDN/Edge: Cachelagring, hastighetsbegränsningar och IP-rykte

Mellan klient och ursprung beslutar CDN, reverse proxies och DDoS-skyddssystem om Kulvert och gasa. Jag kontrollerar om kritiska rutter cachelagras korrekt (stale-while-revalidate, stale-if-error) och om negativa cachelagringar håller kvar fel längre än nödvändigt. Hastighetsgränser, bot-hantering och IP-rykte kan dämpa legitim trafik, särskilt med delade nätverk eller omfattande API-åtkomst. Jag segmenterar trafik (t.ex. API vs. tillgångar), definierar tydliga cache-nycklar och avaktiverar regler selektivt för betrodda klienter. Detta avlastar Origin och förhindrar att CDN-köerna växer medan servern ser ut att vara „underutnyttjad“.

Containrar och orkestrering: cgroups, Ingress och conntrack

I behållare gäller cgruppsgränser för CPU, RAM, pids och filer. En CPU-kvot som är för snäv leder till strypning: processer väntar på CPU-tid även om värden är ledig. Jag kontrollerar kvoter och ser till att ingress/proxy-pods har tillräckligt med fildeskriptorer och buffertar. I Kubernetes kontrollerar jag ingress-timeouts, readiness/liveness-probes och tjänsteimplementeringar (IPVS), eftersom felaktiga probes eller timeouts genererar zigzag-latens och onödiga omstarter.

En ofta förbisedd flaskhals är NAT/conntrack-kapacitet per nod. Många kortlivade anslutningar (t.ex. egress till externa API:er) fyller conntrack-tabellen, sedan „försvinner“ förfrågningar i nätverket. Jag skalar tabellen, ställer in realistiska timeouts och buntar ihop externa anrop så att färre nya anslutningar skapas. Jag planerar PodDisruptionBudgets, rullande uppdateringar och HPA-skalning på ett sådant sätt att ingen kapacitet dras från schemaläggaren vid toppar - annars bildas köer, även om appen teoretiskt skulle ha tillräckligt med arbetare.

Observerbarhet: korrelation, spårning och meningsfulla mätvärden

För att snabbt hitta blockeringar behöver jag Kontinuerlig korrelation. Jag tilldelar förfrågnings-ID:n (t.ex. traceparent) till edge, webbservern, appen och databasen och skriver dem i loggarna. På så sätt kan jag se om en begäran misslyckas i WAF, väntar på webbservern, har fastnat i FPM-kön eller blockeras i databasen. Jag arbetar med Histogram istället för rena medelvärden och övervakar P95/P99-latens, öppna anslutningar, acceptkö, FPM-kölängd, aktiva DB-sessioner och backend-felkoder. Jag använder också syntetiska kontroller för att tydligt separera effekter på klientsidan från effekter på serversidan.

För anomalier använder jag en DrilldownProceduren: först edge/WAF-loggar, sedan lastbalanserare, sedan webbserveråtkomst/fel, sedan app- och FPM-loggar och slutligen DB- och systemloggar. Den här vägen visar mig exakt var tiden går förlorad och vid vilken gräns begäran stannar. Med riktade mätvärden per lager undviker jag magkänslor och minskar drastiskt tiden till grundorsaken.

Spelbok och checklista för tuning

I praktiken har jag en kompakt spelbok som jag anpassar till miljön:

• Reproducerbarhet: Spika ner scenario (rutt, metod, storlek, klient), logga tidsstämpel och ID.
• Kontrollera lager för lagerWebbläsare/tillägg, CORS/Preflight, WAF-Hits, LB-Stats, Webserver-Status, FPM-Queue, DB-Active/Locks.
• Gör köerna synligaAccept/SYN-backlog, FPM-lyssningskö, proxy-backlog, DB-anslutningspool.
• Synkronisera gränserWorker/threads, somaxconn, nofile, max_connections, stream limits för H2/H3, body/header limits, timeouts.
• Minska beläggningstidenSnabba upp sökningar, undvik sessionslås, minska I/O, komprimera svar och cacha dem på ett förnuftigt sätt.
• Harmonisera strategierKeep-Alive-varaktighet, HTTP/2/3-parametrisering, prioritering av kritiska vägar.
• Justera säkerheten: Riktad uteslutning av WAF-regler i stället för global försvagning; loggning med träff-ID.
• SkalningDefiniera samtidighet per skift, kör belastningstester, mät reserver, öka gränserna först efter optimering.
• FallbackarStrömbrytare för långsamma backends, policy för omprövning med jitter, „stale-if-error“ för kritiska tillgångar.

Kortfattat sammanfattat

Blockerade förfrågningar med ledig CPU och RAM orsakas vanligtvis av begränsningar, filter och anslutningsstrategier - inte av bristande prestanda. Jag kontrollerar först var begäran stannar: webbläsare, WAF, webbserver, runtime eller databas. Sedan minimerar jag beläggningstiden per slot, tar bort onödiga Lås och ställer in realistiska tidsgränser. Jag håller säkerheten hög, justerar regler mot falsklarm och samlar in bevis i loggar. Med det här tillvägagångssättet förblir HTTP-förfrågningar tillförlitligt tillgängliga - även när trafiken ökar och varje sekund räknas.