Jämförelse av PHP-hanterare: Effekter på webbhotellets prestanda

Denna jämförelse av PHP-hanterare visar hur mod_php, CGI, FastCGI, PHP-FPM och LSAPI hanterar Prestanda påverkar din hosting – från CPU-belastning till tail-latenser. Jag förklarar konkret vilket val som är bäst för WordPress, WooCommerce och trafiktoppar. Laddningstid sänker och samtidigt sparar resurser.

Centrala punkter

• PHP-FPM skalar mer effektivt än mod_php och FastCGI.
• LSAPI levererar de bästa värdena på LiteSpeed.
• Isolering per användare ökar säkerheten.
• OPcache och Redis minskar latensen.
• P95/P99 visar verklig användarupplevelse.

Hur PHP-hanterare fungerar

En PHP-hanterare kopplar samman webbservern med tolken och styr Processer, minne och I/O för varje förfrågan. CGI startar en ny process för varje förfrågan och laddar om konfigurationer, vilket skapar overhead och Fördröjning ökar. Moderna varianter som FastCGI, PHP-FPM eller LSAPI håller arbetare tillgängliga och sparar därmed starttid, kontextbyten och CPU-cykler. OPcache förblir i minnet, vilket innebär att bytecode inte behöver kompileras varje gång och dynamiska sidor svarar snabbare. Samtidigt avgör processhanteringen hur många samtidiga förfrågningar som får köras, hur prioriteringar ska sättas och hur belastningstoppar kan dämpas.

Direktjämförelse av vanliga hanterare

Valet av hanterare avgör Skalning, säkerhetsmodellen och RAM-behovet för en applikation. mod_php integrerar PHP i Apache-processen och ger korta svarstider, men lider av svag Isolering mellan konton. CGI separerar användare på ett rent sätt, men kostar mycket CPU-tid per förfrågan. FastCGI minskar overheadkostnaden, men är mindre effektivt än ett väljusterat PHP-FPM. LSAPI går ett steg längre när LiteSpeed används och stabiliserar särskilt tail-latensen vid många samtidiga anslutningar.

handlare	Prestanda	Säkerhet	Krav på RAM-minne	Skalbarhet	Operativt scenario
mod_php	Hög	Låg	Låg	Medium	Små webbplatser, sällsynta toppar
CGI	Låg	Hög	Hög	Låg	Statiskt innehåll, tester
FastCGI	Medium	Medium	Medium	Medium	tillfällig lösning
PHP-FPM	Mycket hög	Hög	Låg	Hög	Delad hosting, CMS
LSAPI	Högsta	Medium	Mycket låg	Mycket hög	Hög trafik, e-handel

PHP-FPM i praktiken: processer, pooler, tuning

PHP-FPM arbetar med arbetspooler som hämtar förfrågningar från en kö och därmed Belastningstoppar elegant dämpa. Jag sätter upp en egen pool per webbplats så att konfiguration, gränser och användarkontext förblir separata och Säkerhet ökar. I praktiken lönar sig adaptiva inställningar som pm = dynamic eller ondemand, eftersom antalet aktiva processer anpassas efter efterfrågan. Det är viktigt att dimensionera pm.max_children och tidsgränserna korrekt så att kön inte växer och det fortfarande finns RAM-reserver kvar. Till att börja med rekommenderar jag att du kontrollerar parametrarna på ett strukturerat sätt. Detaljer om finjustering förklarar jag här: PHP-FPM-processhantering.

LSAPI och LiteSpeed: toppvärde vid hög samtidighet

LSAPI håller PHP-processer i minnet och minskar kontextbyten, vilket gör att dynamiskt innehåll med HTTP/3 och QUIC levereras ännu smidigare. Under full belastning förblir P95/P99-latensen stabilare än hos många alternativ, vilket gör att Användarupplevelse synligt förbättrad. Jag ser regelbundet fler förfrågningar per sekund och kortare TTFB på butiks- och innehållssidor, särskilt när OPcache och servercache arbetar tillsammans. Fördelen syns inte bara i genomsnittsvärden, utan också vid samtidiga sessioner, sessioner med cache-missar och „kalla“ PHP-arbetare. Om du vill förstå skillnaden i arkitekturen kan du läsa översikten över LiteSpeed vs. Nginx och beslutar sedan om stacken.

WordPress och WooCommerce: Korrekta värden

Med WordPress uppnår jag höga resultat med PHP 8.2 på FPM eller LSAPI. req/s-värden, medan WooCommerce genom sessioner, kundvagnslogik och fler databasåtkomster klarar något färre förfrågningar per sekund. Testet blir först meningsfullt under realistiska Trafik blandat med caching-träffar och -missar. Kritisk CSS, objektcache och persistenta anslutningar flyttar gränsen för när flaskhalsar uppstår. Kort TTL är särskilt användbart för innehåll som ändras ofta och differentierade cache-nycklar för språk, användarstatus och enhetstyp. På så sätt förblir sidan snabb trots att den levererar personaliserat innehåll.

Säkerhet och isolering: pooler, användarkontext, begränsningar

Jag föredrar separata för multi-user-hosting pooler per konto, så att rättigheter, sökvägar och begränsningar hålls åtskilda. mod_php delar en gemensam kontext, vilket gör att Risk ökar om ett projekt har luckor. FPM eller LSAPI med per-användarkonfigurationer minskar denna attackyta avsevärt, eftersom processerna körs under respektive användare. Dessutom finns möjligheten att ställa in olika php.ini-alternativ på projektnivå utan att påverka andra webbplatser. Resursbegränsningar som max_execution_time och memory_limit per pool förhindrar att avvikelser bromsar servern.

Resursanvändning och RAM-planering

Varje PHP-arbetare upptar beroende på kod, tillägg och OPcache-storlek varierar avsevärt, varför jag mäter den faktiska beläggningen istället för att gissa. Verktyg som ps, top eller systemd-cgtop visar hur mycket RAM aktiva arbetare verkligen upptar och när. Swapping hotar. Därefter ställer jag in pm.max_children konservativt, lämnar utrymme för databas, webbserver och cache-tjänster och observerar P95-latensen under toppbelastning. Om det finns reserver ökar jag antalet barn stegvis och kontrollerar igen. På så sätt växer den totala kapaciteten på ett kontrollerat sätt utan att överbelasta servern.

Mätmetodik: Från TTFB till P99

Jag utvärderar inte bara genomsnittsvärden, utan framför allt P95– och P99-latenser, eftersom de återspeglar den verkliga upplevelsen under belastning. En stack kan fungera med identisk genomströmning och ändå fungera sämre vid P99 om Köer växa. Därför testar jag kalla och varma cacher, blandar läs- och skrivförfrågningar och använder realistiska samtidighetsvärden. Utan OPcache-uppvärmning tolkar jag resultaten försiktigt, eftersom många system blir betydligt snabbare efter några få uppvärmningsanrop. Först efter representativa testkörningar fattar jag beslut om hanterare, cachestrategi och processgränser.

Beslutsguide för val av hanterare

För små sidor med få inloggningar räcker mod_php eller ett sparsamt FPM-Inställning, förutsatt att säkerhetsaspekter beaktas. Om samtidigheten ökar byter jag till PHP-FPM med separata pooler per projekt och aktiverar OPcache konsekvent. För mycket dynamiska butiker och många sessioner föredrar jag LiteSpeed med LSAPI för att hålla P95 och P99 låga. Den som av pris- eller arkitekturskäl fortsätter att använda Apache/Nginx klarar sig mycket bra med en väljusterad FPM. I alla fall är mätningar under realistiska förhållanden viktigare än benchmarking på ett tomt system.

Praktisk inställning: Caching, sessioner, tidsgränser

Jag satsar på OPcache med generös Minne-Allokering, så att bytecode sällan trängs undan, och flytta sessioner om möjligt till Redis, för att undvika fillåsning. Detta minskar väntetiderna vid samtidiga inloggningar och personaliserade sidor. För externa tjänster definierar jag tydliga timeouts och circuit breakers så att avbrott inte blockerar hela begäran. På applikationsnivå håller jag cache-TTL:er tillräckligt korta för att upprätthålla aktualiteten, men tillräckligt långa för en hög träfffrekvens. Den som regelbundet stöter på arbetargränser hittar en introduktion här: Balansera PHP-arbetare på rätt sätt.

Kostnads-nyttoanalys och drift

Jag betygsätter Kostnader en förändring mot mätbar vinst i latens, genomströmning och driftsäkerhet. Övergången från FastCGI till PHP-FPM ger ofta mer än en förändring av PHP:s sekundära versionsnummer, eftersom Process-hantering och caching fungerar kontinuerligt. LSAPI är särskilt värdefullt om LiteSpeed redan används och många besökare samtidigt väntar i kö. Den som byter stack bör noga följa loggar och mätvärden och förbereda återställningsvägar. En planerad A/B-drift under flera dagar ger de mest tillförlitliga resultaten.

Webbserver-samverkan: Apache-MPM, Nginx och Keep-Alive

I praktiken är det inte bara PHP-hanteraren som avgör, utan även webbserverns läge. mod_php fungerar med Apache i prefork-MPM, men blockerar användningen av moderna händelsemodeller. Den som vill använda HTTP/2, längre Keep-Alive-faser och tusentals anslutningar på ett effektivt sätt bör satsa på Apache. evenemang + PHP-FPM eller på Nginx/LiteSpeed som frontend. Konsekvensen: Antalet PHP-arbetare som behövs beror inte på antalet TCP-anslutningar, utan på de faktiska på samma gång löpande PHP-förfrågningar. HTTP/2/3-multiplexing minskar alltså overheadkostnaden för rubriker på webbservern, men ändrar inte något på underdimensionerade PHP-pooler.

Nginx vidarebefordrar vanligtvis förfrågningar via FastCGI till FPM. Jag ser till att det går snabbt. read_timeout- och send_timeout-värden på proxyn, annars uppstår 502/504-fel vid hängande uppströms, även om PHP fortfarande fungerar. I Apache-miljöer begränsar jag Keep-Alive så att långa inaktiva anslutningar inte binder trådpoolen. LiteSpeed abstraherar mycket av detta, men utnyttjar sin fördel fullt ut först med LSAPI.

OPcache, JIT och förladdning: vad som verkligen hjälper

OPcache är obligatoriskt. I praktiken dimensionerar jag opcache.minnes_förbrukning generös (t.ex. 192–512 MB beroende på kodbas) och öka opcache.max_accelererade_filer, så att inga evictions uppstår. För builds som sällan distribueras inaktiverar jag validera_tidsstämplar eller sätt ett högre revalidate_freq, för att spara syscalls. Förladdning kan påskynda ramverk, men har framför allt effekt vid en konsekvent autoload-struktur. Det JIT PHP ger sällan fördelar vid klassiska webbarbetsbelastningar och kan till och med kosta RAM-minne. Jag aktiverar det bara om benchmark-tester under verkliga förhållanden bekräftar detta.

Köhantering och backpressure

De flesta flaskhalsar uppstår inte i CPU:n, utan i kö. Om fler förfrågningar kommer in än vad arbetarna kan hantera växer kön och P95/P99-latensen skjuter i höjden. Jag ser till att pm.max_barn är tillräckligt stor för att hantera typiska toppar, men tillräckligt liten för att hålla RAM-reserven. pm.max_förfrågningar Jag sätter den på en moderat nivå (t.ex. 500–2000) så att minnesläckor inte skapar långkörare. listen.backlog måste passa webbserverns backlog, annars bryter kärnan anslutningarna under belastning. Den som mäter ankomstfrekvensen (förfrågningar per sekund) och den genomsnittliga servicetiden kan med hjälp av en enkel kapacitetsberäkning bedöma vid vilken samtidighet latensen tippar över.

Timeouts, uppladdningar och långkörare

Långa uppladdningar eller API-anrop blockerar arbetare. Jag sätter tydliga gränser: max_exekveringstid och begäran_avsluta_timeout i FPM förhindrar att defekta förfrågningar körs i evighet. På proxynivå synkroniserar jag proxy_read_timeout/fastcgi_read_timeout med FPM-gränserna så att det inte uppstår för tidiga 504-fel. Stora uppladdningar strömmar jag och begränsar post_max_storlek och upload_max_filesize strikt och planera dedikerade slutpunkter så att den övriga trafiken inte påverkas negativt. För cron-liknande långkörare flyttar jag arbetet till Ledtrådar eller CLI-jobb, istället för att blockera frontend-arbetare i flera minuter.

Sessioner och låsning i detalj

PHP-sessioner är standard spärrande. En andra begäran från samma användare väntar tills den första frigör sessionen – vilket är ödesdigert för WooCommerce om Ajax-anrop körs parallellt. Jag avslutar skrivåtkomst till sessionen tidigt med session_write_close(), så snart inga mutationer längre behövs. Med Redis som session-backend minskar I/O-latensen, men låsningsreglerna förblir viktiga. Bakom lastbalanserare väljer jag medvetet mellan sticky sessions (enkelt, mindre skalbart) och stateless mönster med objektcache, så att horisontell skalning fungerar smidigt.

Övervakning och felsökning

Utan telemetri är tuning som att flyga i blindo. Jag aktiverar FPM-status och slowlogs per pool för att se flaskhalsar och identifiera frågor som sticker ut.

; per pool pm.status_path = /status ping.path = /ping ping.response = pong request_slowlog_timeout = 3s slowlog = /var/log/php-fpm/www-slow.log pm.max_requests = 1000

Om fel 502/504 uppstår kontrollerar jag först: Är FPM-kön full? Finns det CPU-stöld eller swap? Passar webbserverns timeout med FPM-gränserna? En titt i smaps per arbetare visar faktisk RSS-användning, medan netstat/ss Upptäcka backlog-överflöd. För OPcache observerar jag träfffrekvensen och antalet omvalideringar för att undvika evictions.

Containrar, socklar och resursbegränsningar

I containrar använder jag oftast TCP istället för Unix-socklar mellan webbserver och FPM för att undvika namnområdesgränser och underlätta lastbalansering. Det är viktigt med konsistens. cgroup-Gränser: Om containern endast har 1–2 GB RAM måste pm.max_children vara mindre, annars aktiveras OOM-killer. CPU-kvoter påverkar reaktionstiden kraftigt; jag planerar headroom och verifierar P95-latensen under gränsen. NUMA- och Core-Affinity-frågor blir relevanta vid mycket hög belastning, medan LSAPI i LiteSpeed-konfigurationer optimerar mycket av detta internt.

Flera PHP-versioner och tillägg

Många värdar kör flera PHP-versioner parallellt. Jag isolerar pooler per version och håller Förlängningar smal. Varje extra modul ökar RAM per arbetare och kan förlänga starttiden. Jag tar konsekvent bort oanvända tillägg; det ger ofta mer än en mindre ökning av pm.max_children. Vid uppgraderingen planerar jag in korta uppvärmningsfaser för OPcache, så att inte alla användare upplever kalla starter samtidigt efter implementeringen.

RAM-diet och realistisk kapacitetsplanering

Istället för generella värden beräknar jag det genomsnittliga och maximala RAM-behovet per arbetare med live-trafik. Av detta drar jag följande slutsats: (tillgängligt RAM – system/DB/cacher) / RAM per arbetare = maximal meningsfullt pm.max_children. Dessutom håller jag 15–25 % i reserv för burst, kernelcache och oförutsedda toppar. Om applikationen sporadiskt blåser upp minnet sänker jag gränsen eller minskar pm.max_requests för att återvinna processer oftare.

Teststrategi: Reproducerbar belastning och verkliga mönster

Jag använder testprofiler som blandar kalla och varma cacher, kombinerar GET/POST och ökar samtidigheten stegvis. Viktigt: Först med aktiv OPcache och realistiska tänkningstider kan jag se om systemet förblir stabilt under användningsbeteendet. En ramp-up över flera minuter förhindrar artificiella toppar vid start. Utvärderingen fokuserar på TTFB och P95/P99, inte bara på genomsnittlig RTT eller rena req/s.

Felbilder från praktiken

• Många 504 under Peak: FPM-kö full, backlog för liten, timeouts på proxyn snävare än i FPM.
• Stammning vid distributioner: OPcache-förskjutningar, saknad uppvärmning, för liten opcache.memory_consumption.
• Bra genomsnittsvärden, dåliga P99: För många långkörare (I/O, externa API:er), saknad circuit breaking.
• Hög CPU, låg req/s: Sessionslås eller icke-cachelagrade databasfrågor som begränsar seriekörningen.

Driftsäkerhet och återställning

Varje ändring av hanteraren eller poolparametrarna kör jag med Funktion flaggor eller stegvis. Jag håller koll på fel- och slowloggar, P95 och felfrekvens och definierar en tydlig nedmontering om mätvärdena förändras. En andra pool med identisk version, men andra parametrar, möjliggör snabb A/B-växling utan driftstopp. Under full belastning har en kort, automatisk minskning av samtidigheten (backpressure) visat sig vara effektivare än att starta nya arbetare på ett okontrollerat sätt.

Kortfattat sammanfattat

För dynamiska webbplatser med många samtidiga användare föredrar jag LSAPI på LiteSpeed, medan PHP-FPM på Apache eller Nginx ger bästa Allroundspelare mod_php förblir ett specialfall för mycket enkla projekt utan strikt isolering. Avgörande är realistiska tester med varm OPcache, rimliga poolgränser och ren caching. Den som pålitligt minskar latenser mäter P95/P99 och reagerar först på tail-problem istället för på genomsnittsvärden. På så sätt uppnår en applikation märkbart snabbare svar och större reserver för peak-traffic.