PHP Realpath Cache: en underskattad prestandaboost för PHP

Den ofta förbisedda funktionen för snabba PHP-förfrågningar heter PHP Realpath Cache: Den lagrar upplösta sökvägar i arbetsminnet och minskar antalet resurskrävande filsystemförfrågningar vid include/require. I projekt med Symfony, Laravel eller en stor WordPress-installation ökar jag med en välordnad Realpath-konfiguration Prestanda mätbart och håller antalet systemanrop per begäran betydligt lägre.

Centrala punkter

• Enklare Hebel: Realpath lagrar sökvägsupplösningar och minskar antalet åtkomstförfrågningar till filsystemet.
• Per arbetstagare: Varje PHP-FPM-process hanterar sin egen Realpath-cache.
• Storlek Det är viktigt att tänka på: En för liten cache orsakar thrashing och bromsar förfrågningarna.
• TTL styr aktualiteten: Lång TTL för stabila distributioner, kort TTL för symlänkar/hemligheter.
• Övervakning: realpath_cache_get()/size() visar belastning och luckor.

Vad Realpath Cache gör exakt

Vid varje anrop av `include`, `require` eller `file_get_contents` omvandlar PHP relativa sökvägar till absoluta sökvägar och lagrar resultaten i Cache. Om samma sökväg dyker upp igen läser jag ut resultatet från minnet och slipper den kostsamma resan till filsystem. Denna mekanism minskar antalet systemanrop märkbart, särskilt när Composer-autoloading laddar många klasser och konfigurationsfiler. Viktigt: Realpath-cachen finns per process, vilket innebär att varje PHP-FPM-arbetare drar nytta av den först efter några förfrågningar, när den har byggt upp sin egen cache. Detta skapar en kontinuerlig prestandaförbättring som lönar sig särskilt vid hög belastning.

Varför cachen är viktig i stora ramverk

Stora ramverk och många tillägg genererar otaliga per begäran Filåtkomst, som utan cachelagring skulle behöva omvärdera sökvägarna varje gång. Om Realpath-cachen är för liten tränger den undan äldre poster, nya läggs till, och jag observerar ren Slagsmål. Detta resulterar i upprepade stat- och lookup-operationer som tar tid och belastar I/O. I praktiken kan detta minska antalet systemanrop per begäran med cirka 5–15 %, vilket blir en enorm skillnad vid hög begärandefrekvens. Ju mer modulär applikationen är, desto större är effekten av en korrekt dimensionerad Realpath-cache.

Så här beräknar jag rätt cache-storlek

Jag räknar först de unika vägarna för en typisk begäran, beräknar den genomsnittliga vägens längd och lägger till cirka 128 byte per post Overhead. Utifrån antal, sökvägslängd och overhead beräknar jag ett realpath_cache_size som är tillräckligt Buffert erbjuder. Många större projekt hamnar mellan 4 och 16 MiB, och mycket omfattande monorepos kan även överstiga detta. Det är viktigt att cachen inte ligger precis vid gränsen, annars går fördelen förlorad på grund av att den ständigt måste rensas. Jag ökar i steg, övervakar utnyttjandet och justerar därefter.

Rekommenderade inställningar och exempelvärden

Standardvärdena härstammar från en tid då kodbaserna var små och passar ofta inte längre in i dagens Inställningar. För många produktiva applikationer ställer jag in realpath_cache_size på 4096K till 16384K och förlänger realpath_cache_ttl till 360–600 Sekunder eller mer. Avgörande faktorer är projektets storlek, driftsättningsfrekvensen och filsystemets egenskaper. Tabellen nedan visar användbara riktvärden som hjälper till att komma igång med optimeringen. Därefter justerar jag siffrorna utifrån övervakning och belastningstester.

Inställning	Frekventa betalningsförsummelser	Bra utgångsvärden	Förväntad effekt
realpath_cache_storlek	4096K (4 MiB)	4096K–16384K	Reducerad Slagsmål vid många filer
realpath_cache_ttl	120–600 s	360–900 s	Längre Cache-stopp, färre nya upplösningar

Exempel i php.ini: realpath_cache_size = 4096K och för stora ramverk realpath_cache_size = 16384K. Under dess livslängd använder jag ofta realpath_cache_ttl = 360 eller högre vid sällsynta utgivningar. På så sätt förblir sökvägarna i minnet över många förfrågningar utan att ständigt behöva valideras på nytt.

Välj TTL med omtanke – beroende på driftsättning

Vilken TTL som är rätt beror i hög grad på driftsättningsprocessen och användningen av Symlänkar från. När jag växlar mellan olika versioner genom att rotera symboliska länkar får cachen inte leverera föråldrade sökvägar, därför ställer jag in TTL till en kort tid eller utlöser en omstart av FPM efter Utrullning. I Kubernetes-miljöer där Secrets eller ConfigMaps används som volymer minskar jag TTL avsevärt eller inaktiverar Realpath Cache tillfälligt. Mer statiska webbhotellmiljöer drar däremot nytta av längre TTL-värden, eftersom sökvägarna sällan ändras. På så sätt balanserar jag aktualitet och hastighet efter den aktuella miljön.

Övervaka och verifiera

Jag kontrollerar regelbundet med realpath_cache_get(), vilka sökvägar i Cache ligger, och med realpath_cache_size(), hur mycket lagringsutrymme som redan är upptaget. Om användningen ligger nära den konfigurerade storleken ökar jag Kapacitet Steg för steg. Om cachen fylls extremt snabbt tolkar jag det som ett tecken på att det behövs mer minne eller att TTL-tiden är för kort. Efter större plugin-installationer eller uppdateringar av ramverket kontrollerar jag igen. Endast den som känner till siffrorna kan fatta välgrundade beslut om optimering.

Mätbara effekter: Så här mäter jag systemanrop och fördröjningar

För att säkerställa att optimeringen är stabil mäter jag före och efter ändringarna. Under Linux registrerar jag filsystemanrop per begäran med strace eller . perf, antingen på en enskild FPM-workare eller via CLI.

• Enskild begäran (CLI): strace -c -o /tmp/strace.txt php public/index.php ger en översikt över hur många stat(), openat() och lstat() uppkommer.
• Lägg till FPM-arbetare: strace -fp -e trace=file -o /tmp/strace-fpm.log visar endast filrelaterade anrop. Tidigare med ps Ta reda på arbetarens PID.
• Belastningstest: Med verktyg som från eller . hej Jag simulerar belastning och jämför P95/P99-latenser vid olika cache-storlekar.

Samtidigt låter jag PHP visa cacheanvändningen, till exempel i en debug-endpunkt eller via CLI:

<?php
$entries = realpath_cache_get();
$size    = realpath_cache_size();
printf("Poster: %d, Använd: %d byte (%.2f MiB)\n", count($entries), $size, $size/1048576);

Så här ser jag om höjningen av realpath_cache_storlek faktiskt minskar antalet missar och filsystemanrop, istället för att bara binda upp RAM-minne. Idealt sett ökar träfffrekvensen samtidigt som P95-latenserna minskar märkbart.

Så här värmer jag upp Realpath-cachen på ett målinriktat sätt

Eftersom cachen skapas per arbetare lönar det sig att Uppvärmning efter en driftsättning eller omstart. Målet är att de vanligaste inkluderingarna ska hamna i cachen tidigt, innan den riktiga användartrafiken kommer igång.

• Begäran om repriser: Efter lanseringen kör jag automatiskt en handfull typiska URL:er (frontend, admin, API).
• CLI-förberedelse: Ett kort bootstrapping-skript laddar centrala sökvägar (autoloader, kärna, konfiguration, rutter).

<?php
// warmup.php
require __DIR__.'/vendor/autoload.php';  // Composer
require __DIR__.'/config/bootstrap.php'; // Projektberoende
require __DIR__.'/public/index.php';     // Front-Controller (kan utlösa en kort körning)
echo sprintf("Primed %d entries, used %d bytes\n",
    count(realpath_cache_get()), realpath_cache_size());

Denna uppvärmning täcker visserligen inte alla verkliga förfrågningar, men lagrar de vanligaste vägarna och förkortar den inledande kallstartsfasen märkbart för varje arbetare.

Samverkan med OPcache och filsystemets cache

OPcache påskyndar körningen av PHP-filer, medan Realpath förkortar sökvägen till filen, därför kombinerar jag de båda Tekniker. För OPcache-inställningarna använder jag beprövade värden och hänvisar till välgrundade OPcache-optimering, så att bytecode och sökvägar samverkar på bästa sätt. Dessutom drar Realpath nytta av en uppvärmd OS-cache som snabbt levererar kataloguppslag och metadata. På så sätt undviker jag dubbla väntetider vid inläsning och parsning. Den som samordnar båda nivåerna uppnår märkbara förbättringar av svarstiderna.

Utnyttja Composer-autoladdningen på bästa sätt

Composer-Autoloader är en viktig drivkraft för upplösning av sökvägar. Ju mer deterministiskt den fungerar, desto enklare blir det för Realpath Cache.

• Optimera klasskartan: composer dump-autoload -o minskar antalet kataloggenomsökningar och upprepade sökningar.
• Håll dig strikt till autoladdningMed classmap-auktoritativ (Projektinställningar) undviker jag onödiga fallback-lösningar som annars skulle utlösa ytterligare sökvägsupplösningar.
• Ordna strukturen: Platta, enhetliga mappstrukturer och få undantagsfall (t.ex. inkluderingar som sträcker sig över flera moduler eller klienter) stabiliserar belastningen på cachen.

Resultatet: färre olika sökvägar per begäran, ökad återanvändning i Realpath-cachen och därmed lägre IO-kostnader.

FPM och minnesbudget: vad som är realistiskt per arbetare

Eftersom Realpath-cachen finns per process multipliceras den konfigurerade storleken med antalet FPM-arbetare. Jag planerar därför en budget:

• Exempel: 12 arbetare × 8 MiB = 96 MiB Realpath-huvud; till detta kommer OPcache, PHP-heap och overhead för tillägg.
• Balansera: Om OPcache har gott om utrymme kan Realpath få några MiB till – eller tvärtom.
• Poolspecifikt: Olika FPM-pooler (Front, Admin, API) får ha olika Realpath-storlekar, beroende på respektive kods storlek.

Ju mer koden växer med varje release, desto mer växer realpath_cache_storlek-Behovet varierar vanligtvis. Därför kontrollerar jag regelbundet toppbeläggningen under belastning, inte bara vid tomgång.

Särskilda fall: symboliska länkar, behållare och NFS

Vid lanseringar av symlänkar skriver jag en kort TTL eller starta om FPM efter distributionen så att alla arbetare laddar de nya sökvägarna. I containrar med föränderliga volymer ser jag till att cachen inte innehåller föråldrade Mål hanterar detta genom att justera TTL. Vid användning av NFS rekommenderas dessutom en väl genomtänkt OPcache-strategi och så få katalogbyten som möjligt. Om sökvägarna ändras under körning rensar jag vid tveksamhet specifikt med clearstatcache(true) även Realpath-delen. Tydliga distributionsregler förhindrar inkonsekventa tillstånd mellan olika arbetare.

Vanliga hinder och begränsningar

Eftersom cachen är processspecifik måste varje Arbetare Först och främst måste man samla in sökvägar innan effekten träder i kraft. I miljöer med strikta open_basedir-begränsningar fungerar Realpath-cachen endast i begränsad utsträckning, därför tar jag hänsyn till detta Gränser vid planeringen. För små cacher leder till thrashing, för stora cacher slösar bort RAM – jag letar efter kurvans topp genom mätningar. Dessutom beaktar jag att Realpath inte är en cache för metadata eller innehåll, utan uteslutande lagrar sökvägsupplösningar. Den som har felaktiga förväntningar förbiser orsaker som ligger någon annanstans.

Driftsäkerhet: typiska felmönster och snabba kontroller

Vissa symptom tyder tydligt på problem med Realpath – och kan snabbt verifieras:

• Stora variationer i latens efter driftsättning: Antingen för lång TTL vid rotation av symboliska länkar eller att uppvärmningen uteblivit. Lösning: kort TTL, omstart av FPM, följt av priming.
• Många upprepade stat()-visningarMed strace synligt; ofta är cacheminnets storlek för liten eller så tränger vissa dynamiska sökvägar undan ”hot entries”.
• Stor variation mellan arbetarna: Olika cacher per process. Lösning: konsekvent uppvärmning och jämn fördelning av förfrågningar.

Ofta räcker det med en snabb hälsokontroll med PHP:

<?php
$entries = realpath_cache_get();
$byDir = 0; $byFile = 0;
foreach ($entries as $e) { $e['is_dir'] ? $byDir++ : $byFile++; }
printf("Mappar: %d, Filer: %d, Använt: %.2f MiB\n", $byDir, $byFile, realpath_cache_size()/1048576);

På så sätt kan jag se om det framför allt är kataloger (många moduler, leverantörsstrukturer) eller filer (många konfigurationsfiler/klasser) som dominerar cachen – och anpassa strukturen eller storleken därefter.

Stat-cache kontra Realpath-cache: att medvetet skilja mellan dem

Förutom Realpath-cachen hanterar PHP även en Stat-Cache för resultat från stat() och liknande uppmaningar. Båda cacharna kan hanteras med clearstatcache() påverka:

• clearstatcache() tömmer statistikcachen (valfritt för en specifik fil).
• clearstatcache(true) tömmer dessutom Realpath-cachen.

I sällsynta fall – till exempel vid långkörande CLI-arbetare med dynamiska monteringar eller vid hot-swaps – använder jag en riktad clearstatcache(true)-Hook efter kända ändringar. I övrigt låter jag TTL fungera och undviker onödiga ogiltigförklaringar.

Praktisk genomgång av webbhotellsmiljöer

Jag fastställer först projektets omfattning, det vill säga hur många filer en typisk begäran laddar, och kontrollerar därefter belastningen på Cacher. Därefter väljer jag ett värde för realpath_cache_size som rymmer alla ofta använda sökvägar plus en reserv, och ställer in en TTL som passar distributionscyklerna. Därefter följer jag effekterna med hjälp av övervakning och loggar och justerar värdena försiktigt, istället för att höja dem kraftigt. Dessutom lönar det sig att ta en titt på operativsystemets cache, till exempel på inställningen i Linux VFS-cache-tryck, eftersom Realpath drar nytta av snabba kataloguppslag. På så sätt kan jag införa förbättringar utan att förbise eventuella bieffekter.

Omfattning och konfigurationsvägar: var jag anger vilket värde

Beroende på miljön hanterar jag parametrarna på olika ställen:

• Globalt: php.ini för systemomfattande standardinställningar.
• Pro-Pool: I FPM-pooler per php_admin_value[realpath_cache_size] och php_admin_value[realpath_cache_ttl] dimensionera specifikt för frontend/API.
• Pro-katalogen: I .användare.ini (om det är tillåtet), vilket är lämpligt i miljöer med delad hosting.

Viktigt: Ändringar i php.ini och FPM-poolkonfigurationer kräver en omstart eller en omladdning för att arbetare ska starta med de nya värdena.

CLI, köarbetare och cron-jobb: samma regler, olika körningstider

CLI-skript och köhanterare drar också nytta av Realpath-cachen – dock är Livslängd ofta annorlunda:

• Kortvariga CLI-jobb: Cachen skapas på nytt vid varje anrop. Här hjälper varken uppvärmning eller lång TTL särskilt mycket; det viktiga är snarare att storleken är tillräcklig så att upprepade inkluderingar i själva jobbet lagras i cachen.
• Daemoner/Arbetare: Långvariga processer (Supervisor, Systemd) bygger upp en stabil cache. Efter en Uppdatera kod (Deploy) bör processen startas om, annars kan föråldrade sökvägar finnas kvar i cachen.

Att bedöma projektens omfattning och lagringseffekten

En applikation med 4 000 unika sökvägar och en sökvägslängd på 80 byte plus 128 byte overhead per post kräver ungefär 832 KB Minne i Realpath-cachen; jag planerar att avsätta 4 MiB eller mer som reserv. Om kodbasen växer avsevärt på grund av plugins eller moduler, skalar jag upp linjärt och kontrollerar på nytt Träffar versus missar. På delade servrar är jag dessutom uppmärksam på inode-gränser, eftersom för många små filer belastar hela systemet; den här översikten hjälper mig med detta Gränser för inoder. Det är bättre att räkna med en marginal än att ständigt ligga på gränsen. På så sätt sparar jag systemanrop utan onödig RAM-förbrukning.

Kort och koncist: Min plan för biltrimmning

Först mäter jag antalet filer per begäran, sedan ställer jag in en lämplig Cache-storlek och en som passar in i er driftsättningspraxis TTL. Därefter kontrollerar jag belastningen med realpath_cache_get()/size(), justerar stegvis och kombinerar det hela med finjustering av OPcache och OS-cache. Vid lansering av symlänkar håller jag TTL kort eller startar om FPM, medan jag i statiska miljöer använder långa livstider. Målet är fortfarande en hög cache-träfffrekvens utan slöseri med RAM-minne. På så sätt utnyttjar jag Realpath-cachen som en underskattad prestandaboost för jämn PHP-prestanda.