Hoppa till innehåll 
Denna artikel visar hur trådpool webbserver Konfiguration för Apache, NGINX och LiteSpeed Parallellitet, latens och minnesbehov styrs. Jag förklarar vilka inställningar som är viktiga under belastning och var självjustering räcker – med tydliga skillnader i antal förfrågningar per sekund.
Centrala punkter
- Arkitektur: Processer/trådar (Apache) vs. händelser (NGINX/LiteSpeed)
- Självavstämning: Automatisk anpassning minskar latens och avbrott
- Resurser: CPU-kärnor och RAM avgör lämpliga trådstorlekar
- Arbetsbelastning: I/O-intensiva processer kräver fler trådar, CPU-intensiva processer färre.
- Tuning: Små, målinriktade parametrar har större effekt än generella värden.
Jämförelse av trådpoolarkitekturer
Jag börjar med Arkitektur, eftersom det definierar gränserna för tuningutrymmet. Apache använder processer eller trådar per anslutning, vilket kräver mer RAM och ökar latensen under högtrafik [1]. NGINX och LiteSpeed använder en händelsestyrd modell där ett fåtal arbetare multiplexerar många anslutningar, vilket sparar kontextbyten och minskar overhead [1]. I tester hanterade NGINX 6 025,3 förfrågningar/s, Apache kom i samma scenario upp till 826,5 förfrågningar/s och LiteSpeed tog ledningen med 69 618,5 förfrågningar/s [1]. Om du vill fördjupa dig i arkitekturjämförelsen hittar du ytterligare nyckeldata under Apache vs NGINX, som jag använder för en första klassificering.
Det är också viktigt hur varje motor hanterar blockerande uppgifter. NGINX och LiteSpeed kopplar bort händelseslingan från filsystemet eller uppströms-I/O via asynkrona gränssnitt och begränsade hjälptrådar. Apache binder en tråd/process per anslutning i den klassiska modellen; med MPM event kan Keep-Alive avlastas, men minnesavtrycket per anslutning förblir högre. I praktiken innebär detta att ju fler samtidiga långsamma klienter eller stora uppladdningar, desto mer lönsam blir händelsemodellen.
Hur självjustering verkligen fungerar
Moderna servrar kontrollerar Tråd-antalet ofta automatiskt. Kontrollenheten kontrollerar belastningen i korta cykler, jämför aktuella värden med historiska värden och skalar poolens storlek uppåt eller nedåt [2]. Om en kö fastnar förkortar algoritmen sin cykel och lägger till ytterligare trådar tills bearbetningen återigen löper stabilt [2]. Detta sparar ingrepp, förhindrar överallokering och minskar sannolikheten för head-of-line-blockeringar. Som referens använder jag det dokumenterade beteendet hos en självjusterande styrenhet i Open Liberty, som tydligt beskriver mekaniken [2].
Jag är uppmärksam på tre faktorer: en Hysteres mot flapping (ingen omedelbar reaktion på varje spik), en hård övre gräns mot RAM-överskridningar och en minsta storlek, så att uppvärmningskostnader inte uppstår vid varje burst. Det är också lämpligt att ha ett separat målvärde för aktiv Trådar (coreThreads) vs. maximala trådar (maxThreads). På så sätt förblir poolen aktiv utan att binda resurser i tomgång [2]. I delade miljöer begränsar jag expansionsgraden så att webbservern inte aggressivt tar CPU-slots från närliggande tjänster [4].
Nyckeltal från benchmarking
Reala värden hjälper till med Beslut. I burst-scenarier utmärker sig NGINX med mycket låg latens och hög stabilitet [3]. Vid extrem parallellitet levererar Lighttpd i tester det högsta antalet förfrågningar per sekund, medan OpenLiteSpeed och LiteSpeed ligger tätt efter [3]. NGINX klarar stora filöverföringar med upp till 123,26 MB/s, OpenLiteSpeed ligger strax efter, vilket understryker effektiviteten i den händelsestyrda arkitekturen [3]. Jag använder sådana nyckeltal för att bedöma var trådjusteringar verkligen ger nytta och var begränsningarna kommer från arkitekturen.
| Server | Modell/trådar | Exempel på ränta | kärnbudskap |
|---|---|---|---|
| Apache | Process/tråd per anslutning | 826,5 förfrågningar/sekund [1] | Flexibel, men högre RAM-behov |
| NGINX | Händelse + få arbetare | 6 025,3 förfrågningar/sekund [1] | Låg Fördröjning, sparsam |
| LiteSpeed | Händelse + LSAPI | 69 618,5 förfrågningar/sekund [1] | Mycket snabb, GUI-optimering |
| Lighttpd | Händelse + Asynkron | 28 308 förfrågningar/sekund (hög parallellitet) [3] | Skalas i Tips mycket bra |
Tabellen visar relativa Fördelar, inga fasta löften. Jag utvärderar dem alltid i relation till mina egna arbetsbelastningar: korta dynamiska svar, många små statiska filer eller stora strömmar. Avvikelser kan bero på nätverk, lagring, TLS-avlastning eller PHP-konfiguration. Därför korrelerar jag mätvärden som CPU-stöld, kö-längd och RSS per arbetare med antalet trådar. Först denna syn skiljer verkliga trådflaskhalsar från I/O- eller applikationsgränser.
För att få tillförlitliga siffror använder jag ramp-up-faser och jämför p50/p95/p99-latenser. En brant p99-kurva vid konstanta p50-värden tyder snarare på köer än på ren CPU-mättnad. Öppna (RPS-styrda) istället för slutna (endast samtidighetsstyrda) belastningsprofiler visar dessutom bättre var systemet börjar aktivt avvisa förfrågningar. På så sätt kan jag definiera den punkt där trådökningar inte längre ger någon effekt och backpressure eller hastighetsbegränsningar är mer meningsfulla.
Praxis: Dimensionera arbetare och anslutningar
Jag börjar med CPU-Kärnor: worker_processes respektive LSWS-Worker får inte överskrida kärnorna, annars ökar kontextbytet. För NGINX anpassar jag worker_connections så att summan av anslutningar och filbeskrivare förblir under ulimit-n. För Apache undviker jag för höga MaxRequestWorkers, eftersom RSS per barn snabbt äter upp RAM-minnet. Under LiteSpeed håller jag PHP-processpooler och HTTP-arbetare i balans så att PHP inte blir en flaskhals. Den som vill förstå hastighetsskillnaderna mellan motorerna har nytta av jämförelsen. LiteSpeed jämfört med Apache, som jag använder som bakgrund för tuning.
En enkel tumregel: Jag beräknar först FD-budgeten (ulimit-n minus reserv för loggar, uppströms och filer), delar den med de planerade samtidiga anslutningarna per arbetare och kontrollerar om summan räcker för HTTP + uppström + TLS-buffert. Därefter dimensionerar jag backlog-kön moderat – tillräckligt stor för bursts, tillräckligt liten för att inte dölja överbelastning. Slutligen ställer jag in Keep-Alive-värdena så att de passar förfrågningsmönstren: korta sidor med många tillgångar gynnas av längre timeouts, API-trafik med få förfrågningar per anslutning gynnas snarare av lägre värden.
LiteSpeed-finjustering för hög belastning
Med LiteSpeed satsar jag på LSAPI, eftersom det minimerar kontextbyten. Så snart jag märker att CHILD-processerna är utnyttjade ökar jag LSAPI_CHILDREN stegvis från 10 till 40, vid behov upp till 100 – varje gång åtföljt av CPU- och RAM-kontroller [6]. GUI underlättar för mig att skapa lyssnare, portdelningar, vidarebefordringar och inläsning av .htaccess, vilket påskyndar ändringar [1]. Under kontinuerlig belastning testar jag effekten av små steg istället för stora hopp för att tidigt upptäcka latensspikar. I delade miljöer sänker jag coreThreads när andra tjänster belastar CPU:n, så att självavstämningen inte håller för många aktiva trådar [2][4].
Dessutom observerar jag Keep-Alive per lyssnare och användningen av HTTP/2/HTTP/3: Multiplexing minskar antalet anslutningar, men ökar minnesbehovet per socket. Jag håller därför sändningsbufferten konservativ och aktiverar komprimering endast där nettovinsten är tydlig (många textbaserade svar, knappt CPU-begränsning). För stora statiska filer förlitar jag mig på Zero-Copy-mekanismer och begränsar samtidiga nedladdningsslots så att PHP-arbetare inte svälter när trafiktoppar inträffar.
NGINX: Effektiv användning av händelsemodellen
För NGINX ställer jag in worker_processes på bil eller kärnantalet. Med epoll/kqueue, aktiv accept_mutex och anpassade backlog-värden håller jag anslutningsacceptansen jämn. Jag ser till att ställa in keepalive_requests och keepalive_timeout så att tomgångssocklar inte blockerar FD-poolen. Stora statiska filer skickar jag med sendfile, tcp_nopush och en lämplig output_buffers. Jag använder endast hastighetsbegränsning och anslutningsbegränsningar om bots eller bursts indirekt belastar trådpoolen, eftersom varje begränsning genererar ytterligare statushantering.
I proxyscenarier är Upstream-Keepalive Avgörande: för lågt värde ger upphov till fördröjningar vid upprättande av anslutningar, för högt värde blockerar FD:er. Jag väljer värden som passar backend-kapaciteten och håller timeouts för connect/read/send tydligt åtskilda så att defekta backends inte blockerar event-looparna. Med reuseport och valfri CPU-affinitet fördelar jag belastningen jämnare över kärnorna, så länge IRQ-/RSS-inställningarna för NIC stöder detta. För HTTP/2/3 kalibrerar jag försiktigt header- och flödeskontrollgränser så att enskilda stora strömmar inte dominerar hela anslutningen.
Apache: Ställ in MPM event korrekt
I Apache använder jag evenemang istället för prefork, så att Keep-Alive-sessioner inte binder arbetare permanent. Jag ställer in MinSpareThreads och MaxRequestWorkers så att Run-Queue per kärna förblir under 1. Jag håller ThreadStackSize liten så att fler arbetare får plats i det tillgängliga RAM-minnet; den får inte bli för liten, annars riskerar du stacköverflöd i moduler. Med en moderat KeepAlive-timeout och begränsade KeepAliveRequests förhindrar jag att få klienter blockerar många trådar. Jag flyttar PHP till PHP-FPM eller LSAPI så att webbservern själv förblir lätt.
Jag är också uppmärksam på förhållandet mellan ServerLimit, ThreadsPerChild och MaxRequestWorkers: dessa tre avgör tillsammans hur många trådar som faktiskt kan skapas. För HTTP/2 använder jag MPM event med måttliga strömgränser; för höga värden driver upp RAM-förbrukningen och schemaläggningskostnaderna. Moduler med stora globala cacher laddar jag bara när de behövs, eftersom fördelarna med Copy-on-Write försvinner så snart processer körs länge och minnet förändras.
RAM och trådar: Beräkna minnet korrekt
Jag räknar RSS per arbetare/barn gånger planerat maximalt antal och lägger till kärnbuffertar och cacher. Om det inte finns någon buffert kvar minskar jag trådar eller ökar aldrig swappen, eftersom swappning får latensen att explodera. För PHP-FPM eller LSAPI beräknar jag dessutom den genomsnittliga PHP-RSS så att summan av webbserver och SAPI förblir stabil. Jag tar hänsyn till TLS-termineringskostnader, eftersom certifikathandskakningar och stora utgående buffertar ökar förbrukningen. Först när RAM-budgeten är i balans drar jag åt trådskruvarna ytterligare.
För HTTP/2/3 tar jag hänsyn till ytterligare header-/flödeskontrollstatus per anslutning. GZIP/Brotli buffrar komprimerade och okomprimerade data samtidigt, vilket kan innebära flera hundra KB extra per begäran. Jag planerar också in reserver för loggar och temporära filer. För Apache ökar mindre ThreadStackSize-värden densiteten, medan för NGINX och LiteSpeed är det främst antalet parallella socklar och storleken på sändnings-/mottagningsbuffertarna som påverkar. Att summera alla komponenter före optimeringen sparar dig från obehagliga överraskningar senare.
När jag ingriper manuellt
Jag förlitar mig på Självavstämning, tills mätvärden visar motsatsen. Om jag delar maskinen i delad hosting, bromsar jag coreThreads eller MaxThreads så att andra processer behåller tillräckligt med CPU-tid [2][4]. Om det finns en hård trådgräns per process, ställer jag in maxThreads konservativt för att undvika OS-fel [2]. Om mönster som liknar deadlock uppstår ökar jag endast poolstorleken tillfälligt, observerar köerna och sänker sedan igen. Den som vill jämföra typiska mönster med mätvärden hittar ledtrådar i Jämförelse av webbserverns hastighet, som jag gärna använder som en rimlighetskontroll.
Som ingripningssignaler använder jag främst: ihållande p99-toppar trots låg CPU-belastning, ökande socket-köer, kraftigt växande TIME_WAIT-siffror eller en plötslig ökning av öppna FD:er. I sådana fall begränsar jag först antaganden (anslutnings-/hastighetsbegränsningar), kopplar bort backends med timeouts och ökar sedan försiktigt antalet trådar. På så sätt undviker jag att bara flytta överbelastningen internt och försämra latensen för alla.
Vanliga fel och snabba kontroller
Jag ser ofta till hög Keep-Alive-timeouts som binder trådar även om ingen data flödar. Också vanligt: MaxRequestWorkers långt över RAM-budgeten och ulimit-n för lågt för målparallelliteten. I NGINX underskattar många FD-användningen genom uppströmsanslutningar; varje backend räknas dubbelt. I LiteSpeed växer PHP-pooler snabbare än HTTP-arbetare, vilket innebär att förfrågningar accepteras men hanteras för sent. Med korta belastningstester, heap-/RSS-jämförelser och en titt på köerna hittar jag dessa mönster på några minuter.
Också vanligt: syn-backlog för liten, så att anslutningar studsar tillbaka redan före webbservern; åtkomstloggar utan buffert som skriver synkroniserat till långsam lagring; felsöknings-/spårningsloggar som av misstag förblir aktiva och binder CPU. Vid övergången till HTTP/2/3 ökar för generösa strömgränser och header-buffertar minnesförbrukningen per anslutning – särskilt märkbart när många klienter överför lite data. Jag kontrollerar därför fördelningen av korta respektive långa svar och justerar gränserna därefter.
HTTP/2 och HTTP/3: Vad de betyder för trådpooler
Multiplexing minskar antalet TCP-anslutningar per klient avsevärt. Det är bra för FD och Accept-kostnader, men flyttar trycket till per-anslutningsstatus. Jag ställer därför in försiktiga gränser för samtidiga strömmar för HTTP/2 och kalibrerar flödeskontrollen så att enskilda stora nedladdningar inte dominerar anslutningen. Med HTTP/3 elimineras TCP-relaterade head-of-line-blockeringar, men CPU-användningen per paket ökar. Jag kompenserar detta med tillräcklig arbetskapacitet och små buffertstorlekar så att latensen förblir låg. I alla fall gäller: hellre färre, väl utnyttjade anslutningar med rimliga Keep-Alive-värden än överlånga tomgångssessioner som binder trådar och minne.
Plattformsfaktorer: kärna, container och NUMA
När det gäller virtualisering är jag uppmärksam på CPU-stöld och cgroups-begränsningar: Om hypervisorn stjäl kärnor eller containern endast har delkärnor kan worker_processes=auto vara för optimistiskt. Vid behov fäster jag arbetare till verkliga kärnor och anpassar antalet till effektiv tillgänglig budget. På NUMA-värdar drar webbservrar nytta av lokal minnesallokering; jag undviker onödiga cross-node-åtkomster genom att gruppera arbetare per socket. Jag låter ofta Transparent Huge Pages vara inaktiverat för latenskritiska arbetsbelastningar för att undvika page fault-toppar.
På OS-nivå kontrollerar jag filbeskrivningsgränser, anslutningsbackloggar och portintervallet för utgående anslutningar. Jag ökar bara det jag faktiskt behöver, testar beteendet vid rollover och håller strikt till säkerhetsgränserna. På nätverkssidan ser jag till att RSS/IRQ-fördelningen och MTU-inställningarna passar trafikprofilen – annars går optimeringen på webbservern förlorad eftersom paketen anländer för långsamt eller fastnar i NIC-kön.
Mäta istället för att gissa: Praktisk guide för tester
Jag utför belastningstester i tre steg: uppvärmning (cache, JIT, TLS-sessioner), platå (stabil RPS/samtidighet) och burst (korta toppar). Separata profiler för statiska filer, API-anrop och dynamiska sidor hjälper till att isolera var trådar, I/O eller backends begränsar. Jag noterar parallellt FD-siffror, run-queues, kontextbyten, RSS per process och p50/p95/p99-latenser. Som mål väljer jag driftpunkter vid 70–85 %-utnyttjande – tillräckligt med buffert för verkliga fluktuationer utan att permanent köra i mättnadsområdet.
Beslutsguide i korthet
Jag väljer NGINX, när låg latens, sparsamma resurser och flexibla .conf-inställningsmöjligheter är viktiga. Jag använder LiteSpeed när PHP-belastningen dominerar, GUI ska förenkla driften och LSAPI minskar flaskhalsarna. Jag använder Apache när jag är beroende av moduler och .htaccess och har full kontroll över MPM-event-konfigurationen. I många fall räcker självjusteringsmekanismerna; jag behöver bara ingripa när mätvärdena indikerar hängningar, hårda gränser eller RAM-tryck [2]. Med realistiska kärn- och RAM-budgetar, små stegstorlekar och observation av latenskurvorna leder trådjusteringen mig pålitligt till målet.
