Cache Realpath di PHP: un “turbo” sottovalutato per le prestazioni di PHP

La funzione, spesso trascurata, che consente di eseguire richieste PHP veloci si chiama PHP Realpath Cache: memorizza i percorsi risolti nella memoria di lavoro e riduce le costose interrogazioni del file system durante l'esecuzione di include/require. Nei progetti con Symfony, Laravel o una configurazione WordPress di grandi dimensioni, con una configurazione Realpath ben strutturata riesco ad aumentare la Prestazioni misurabile e mantengo il numero di chiamate di sistema per ogni richiesta nettamente inferiore.

Punti centrali

• Più semplice Leva: Realpath memorizza le risoluzioni dei percorsi e riduce gli accessi al file system.
• Per lavoratore: Ogni processo PHP-FPM gestisce la propria cache Realpath.
• Dimensione Da tenere presente: una cache troppo piccola provoca il thrashing e rallenta le richieste.
• TTL Determina la frequenza di aggiornamento: TTL lungo per distribuzioni stabili, breve per i collegamenti simbolici e i segreti.
• Monitoraggio: realpath_cache_get()/size() mostrano il carico e gli spazi vuoti.

Cosa fa esattamente la cache Realpath

Ogni volta che si utilizza `include`, `require` o `file_get_contents`, PHP converte i percorsi relativi in percorsi assoluti e salva i risultati nel Cache. Se lo stesso percorso si ripete, leggo il risultato dalla memoria e mi risparmio il costoso viaggio verso il sistema di file. Questo meccanismo riduce sensibilmente le chiamate di sistema, soprattutto quando l’autocaricamento di Composer carica numerose classi e file di configurazione. Importante: la cache Realpath esiste per ogni singolo processo, pertanto ogni worker PHP-FPM ne beneficia solo dopo alcune richieste, una volta che ha creato la propria cache. Si ottiene così un effetto di accelerazione costante, particolarmente vantaggioso in caso di carico elevato.

Perché la cache è importante nei grandi framework

I framework di grandi dimensioni e i numerosi plugin generano innumerevoli per ogni richiesta Accessi ai file, che senza la cache dovrebbero risolvere i percorsi ogni volta da capo. Se la cache del percorso reale è troppo piccola, le voci più vecchie vengono sovrascritte, se ne aggiungono di nuove e io osservo puro Battitura. Il risultato sono ripetute operazioni di statistica e ricerca che richiedono tempo e gravano sull’I/O. In pratica, ciò consente di ridurre il numero di chiamate di sistema per richiesta di circa 5–15 %, il che, in caso di elevata frequenza di richieste, comporta un accumulo significativo. Più l’applicazione è modulare, maggiore è l’effetto leva ottenibile tramite una cache Realpath correttamente dimensionata.

Ecco come determinare la dimensione adeguata della cache

Per prima cosa conto i percorsi unici di una richiesta tipica, stimo la lunghezza media del percorso e aggiungo circa 128 byte per ogni voce Spese generali. A partire dal numero, dalla lunghezza del percorso e dall'overhead, calcolo un valore per `realpath_cache_size` che sia sufficiente Buffer offre. Molti progetti di grandi dimensioni occupano tra i 4 e i 16 MiB, mentre i monorepo molto estesi superano anche questa soglia. È importante che la cache non si avvicini troppo al limite, altrimenti ne perdo i vantaggi a causa del continuo svuotamento. Aumento la capacità a piccoli passi, osservo il livello di utilizzo e regolo di conseguenza.

Impostazioni consigliate e valori di esempio

I valori predefiniti risalgono a un'epoca in cui i codici erano di dimensioni ridotte e spesso non sono più adeguati alle esigenze odierne Configurazioni. Per molte applicazioni produttive imposto realpath_cache_size tra 4096K e 16384K e estendo realpath_cache_ttl a 360–600 Secondi o più. I fattori determinanti sono le dimensioni del progetto, la frequenza di distribuzione e le caratteristiche del file system. La tabella seguente fornisce valori di riferimento utili come orientamento e aiuta ad avviare il processo di ottimizzazione. Successivamente, adeguo i valori tramite monitoraggio e test di carico.

Impostazione	Inadempienza frequente	Buoni valori iniziali	Effetto previsto
dimensione_cache_percorso reale	4096K (4 MiB)	4096K–16384K	Ridotto Battitura in presenza di molti file
realpath_cache_ttl	120–600 s	360–900 s	Più lunghe Sospensioni della cache, meno scioglimenti

Esempi nel file php.ini: realpath_cache_size = 4096K e per i framework di grandi dimensioni realpath_cache_size = 16384K. Per la durata di vita utilizzo spesso realpath_cache_ttl = 360 o superiore nel caso di rilasci sporadici. In questo modo i percorsi rimangono in memoria per molte richieste, senza dover essere costantemente convalidati.

Scegliere il TTL in modo oculato – a seconda dell’implementazione

Il TTL corretto dipende in larga misura dal processo di distribuzione e dall'utilizzo di Collegamenti simbolici . Quando passo da una versione all'altra tramite la rotazione dei collegamenti simbolici, la cache non deve fornire percorsi obsoleti; pertanto imposto un TTL breve oppure avvio un riavvio di FPM dopo il Lancio. Negli ambienti Kubernetes che utilizzano Secrets o ConfigMaps come volumi, riduco notevolmente il TTL oppure disattivo temporaneamente la cache Realpath. Le situazioni di web hosting più statiche, invece, traggono vantaggio da TTL più lunghi, poiché i percorsi cambiano raramente. In questo modo riesco a trovare il giusto equilibrio tra aggiornamento e velocità in base all’ambiente.

Monitorare e verificare

Controllo regolarmente con realpath_cache_get(), quali percorsi nel Cache si trovano, e con realpath_cache_size(), quanta memoria è occupata. Se l’utilizzo si avvicina alla dimensione configurata, aumento la Capacità A poco a poco. Se la cache si riempie molto rapidamente, lo interpreto come un segnale che occorre più memoria o che il TTL è troppo breve. Dopo installazioni di plugin di grandi dimensioni o aggiornamenti del framework, ricontrollo. Solo chi conosce i numeri può prendere decisioni sensate in materia di ottimizzazione.

Effetti misurabili: ecco come misuro le chiamate di sistema e le latenze

Per garantire che l’ottimizzazione sia affidabile, effettuo delle misurazioni prima e dopo le modifiche. Su Linux registro le chiamate al filesystem per ogni richiesta con strace oppure perf, a scelta su un singolo worker FPM o sulla CLI.

• Richiesta singola (CLI): strace -c -o /tmp/strace.txt php public/index.php fornisce una panoramica del numero di stat(), openat() e lstat() sorgere.
• Aggiungi un lavoratore FPM: strace -fp -e trace=file -o /tmp/strace-fpm.log mostra solo le chiamate relative ai file. In precedenza con ps Determinare il PID del worker.
• Prova di carico: Con strumenti come da oppure ehi Simulo un carico di lavoro e confronto le latenze P95/P99 con diverse dimensioni della cache.

Contemporaneamente, visualizzo l'utilizzo della cache da PHP, ad esempio in un endpoint di debug o tramite CLI:

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

Ecco come capisco se l'aumento del dimensione_cache_percorso reale riduce effettivamente gli errori e le chiamate al file system, invece di limitarsi a occupare RAM. Idealmente, il tasso di successo aumenta, mentre le latenze P95 diminuiscono sensibilmente.

Ecco come riscaldo in modo mirato la cache Realpath

Poiché la cache viene creata per ogni worker, vale la pena Riscaldamento dopo il deploy o il riavvio. L'obiettivo è che gli include più frequenti vengano memorizzati nella cache il prima possibile, prima che arrivi il traffico degli utenti reali.

• Riproduzioni delle richieste: Dopo il rollout, eseguo automaticamente una serie di URL tipici (frontend, admin, API).
• Inizializzazione della CLI: Uno script di bootstrapping di breve durata carica i percorsi principali (autoloader, kernel, configurazione, route).

<?php
// warmup.php
require __DIR__.'/vendor/autoload.php';  // Composer
require __DIR__.'/config/bootstrap.php'; // A seconda del progetto
require __DIR__.'/public/index.php';     // Front-Controller (può attivare un'esecuzione breve)
echo sprintf("Voci %d preparate, byte %d utilizzati\n",
    count(realpath_cache_get()), realpath_cache_size());

Sebbene questo warm-up non copra tutte le richieste reali, memorizza i percorsi più utilizzati e riduce sensibilmente la fase iniziale di avvio a freddo per ciascun worker.

Interazione con OPcache e la cache del filesystem

OPcache accelera l'esecuzione dei file PHP, mentre Realpath riduce il percorso di accesso al file, quindi li combino entrambi Tecniche. Per le impostazioni di OPcache utilizzo valori collaudati e rimando a fonti attendibili Ottimizzazione OPcache, affinché il bytecode e i percorsi interagiscano in modo ottimale. Inoltre, Realpath beneficia di una cache del sistema operativo “calda”, che fornisce rapidamente le ricerche nelle directory e i metadati. In questo modo evito tempi di attesa duplicati durante il caricamento e l’analisi. Chi coordina entrambi i livelli ottiene miglioramenti tangibili nei tempi di risposta.

Sfruttare al meglio il caricamento automatico di Composer

L'autoloader di Composer è uno dei principali responsabili della risoluzione dei percorsi. Più il suo funzionamento è deterministico, più facile sarà il lavoro della cache Realpath.

• Ottimizzare Classmap: composer dump-autoload -o riduce le scansioni delle directory e le ricerche ripetute.
• Rispettare rigorosamente l'autoloadCon classmap-autorevole (Configurazione del progetto) evito i fallback superflui, che altrimenti causerebbero ulteriori risoluzioni di percorso.
• Organizzare la struttura: Le gerarchie di cartelle piatte e coerenti e il numero limitato di casi particolari (ad esempio, include che coinvolgono più moduli o più mandanti) stabilizzano il carico della cache.

Il risultato: un numero inferiore di percorsi diversi per ogni richiesta, un maggiore riutilizzo nella cache Realpath e, di conseguenza, minori costi di I/O.

FPM e Memory Budget: quali sono i valori realistici per ogni worker

Poiché la cache Realpath esiste per ogni processo, la dimensione configurata si moltiplica per il numero di worker FPM. Prevedo quindi un budget di:

• Esempio: 12 worker × 8 MiB = 96 MiB di Realpath; a ciò si aggiungono OPcache, l'heap di PHP e l'overhead delle estensioni.
• Bilanciare: Se OPcache ha spazio a sufficienza, Realpath può ottenere qualche MiB in più – o viceversa.
• Specifico per la piscina: I diversi pool FPM (Front, Admin, API) possono avere dimensioni del Realpath diverse, in base al rispettivo ingombro del codice.

Se il codice cresce ad ogni release, cresce anche il dimensione_cache_percorso reale-Il fabbisogno è in genere tale. Pertanto, controllo regolarmente l'occupazione di picco sotto carico, non solo a vuoto.

Casi particolari: collegamenti simbolici, container e NFS

In occasione del lancio dei collegamenti simbolici, scrivo una breve TTL oppure riavvia FPM dopo il deploy, in modo che tutti i worker carichino i percorsi aggiornati. Nei container con volume mutabili, mi assicuro che la cache non contenga dati obsoleti Obiettivi regolando il TTL. Su NFS è inoltre consigliabile adottare una strategia OPcache ben definita e ridurre al minimo i cambi di directory. Se i percorsi cambiano durante l'esecuzione, in caso di dubbio svuoto in modo mirato con clearstatcache(true) compresa la parte relativa al percorso reale. Regole di distribuzione chiare impediscono la comparsa di stati incoerenti tra i vari worker.

Ostacoli e limiti tipici

Poiché la cache è associata a ciascun processo, ogni Lavoratore innanzitutto raccogliere i percorsi prima che l'effetto abbia effetto. Nelle configurazioni con forti restrizioni relative a open_basedir, la cache Realpath funziona in modo limitato, pertanto ne tengo conto Confini in fase di progettazione. Le cache troppo piccole causano il thrashing, quelle troppo grandi sprecano RAM: cerco il punto di massimo rendimento attraverso delle misurazioni. Inoltre, tengo presente che Realpath non è una cache di metadati o di contenuti, ma memorizza esclusivamente le risoluzioni dei percorsi. Chi nutre aspettative errate rischia di trascurare le cause che si trovano altrove.

Sicurezza operativa: guasti tipici e controlli rapidi

Alcuni sintomi indicano chiaramente la presenza di problemi con Realpath e possono essere verificati rapidamente:

• Latenza instabile dopo il deploy: O il TTL è troppo lungo durante la rotazione dei collegamenti simbolici, oppure manca il warm-up. Soluzione: TTL breve, riavvio dell'FPM, seguito dal priming.
• Molte ripetute stat()-visualizzazioniCon strace visibile; spesso la dimensione della cache è troppo ridotta oppure determinati percorsi dinamici sostituiscono le voci più frequenti.
• Elevata varianza tra i worker: Cache diverse per ogni processo. Soluzione: un warm-up coerente e una distribuzione uniforme delle richieste.

Spesso è sufficiente un rapido controllo dello stato di salute tramite PHP:

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

In questo modo posso verificare se a dominare la cache siano soprattutto le directory (molti moduli, strutture dei fornitori) o i file (numerose configurazioni/classi) e adeguare di conseguenza la struttura o le dimensioni.

Cache delle statistiche vs. cache del percorso reale: distinguere consapevolmente

Oltre alla cache Realpath, PHP gestisce anche una Cache delle statistiche per i risultati di stat() e comandi simili. Entrambe le cache possono essere gestite con clearstatcache() influenzare:

• clearstatcache() svuota la cache delle statistiche (opzionale per un file specifico).
• clearstatcache(true) svuota inoltre la cache di Realpath.

In casi rari – ad esempio con worker CLI a esecuzione prolungata con mount dinamici o in caso di hot-swap – utilizzo un clearstatcache(true)-Hook in caso di modifiche note. Altrimenti lascio che il TTL faccia il suo lavoro ed evito invalidazioni inutili.

Verifica pratica degli ambienti di hosting

Per prima cosa determino le dimensioni del progetto, ovvero quanti file vengono caricati in una richiesta tipica, e poi verifico il carico di lavoro del Cache. Successivamente, scelgo un valore per `realpath_cache_size` che comprenda tutti i percorsi utilizzati di frequente più una riserva, e imposto un TTL adeguato alla frequenza dei deploy. Dopodiché osservo gli effetti tramite il monitoraggio e i log e adeguo i valori con cautela, invece di aumentarli in modo drastico. Inoltre, vale la pena dare un’occhiata alla cache del sistema operativo, ad esempio all’impostazione di Linux Pressione della cache VFS, poiché Realpath trae vantaggio da ricerche rapide nelle directory. In questo modo posso implementare miglioramenti senza trascurare gli effetti collaterali.

Ambito e percorsi di configurazione: dove impostare ciascun valore

A seconda dell'ambiente, gestisco i parametri in punti diversi:

• Globale: php.ini per le impostazioni predefinite a livello di sistema.
• Pro-Pool: Nei pool FPM per php_admin_value[realpath_cache_size] e php_admin_value[realpath_cache_ttl] dimensionare in modo mirato in base alle esigenze del frontend e dell'API.
• Directory Pro: In .user.ini (se consentito), utile in ambienti di hosting condiviso.

Importante: le modifiche alla php.ini e le configurazioni del pool FPM richiedono un riavvio o un ricaricamento affinché i worker si avviino con i nuovi valori.

CLI, Queue-Worker e cronjob: stesse regole, tempi di esecuzione diversi

Anche gli script CLI e i worker della coda traggono vantaggio dalla cache Realpath, ma la Vita utile spesso diverso:

• Processi CLI di breve durata: Ad ogni chiamata viene ricreata la cache. In questo caso, il warm-up e un TTL elevato servono a poco; è invece importante che la cache abbia dimensioni sufficienti affinché gli include ripetuti nel job stesso vengano memorizzati nella cache.
• Daemon/Worker: I processi a lunga durata (Supervisor, Systemd) creano una cache stabile. Dopo un Ricarica codice (Deploy) il processo dovrebbe riavviarsi, altrimenti nella cache potrebbero rimanere percorsi obsoleti.

Valutazione delle dimensioni dei progetti ed effetto di accumulo

Un’applicazione con 4000 percorsi unici e una lunghezza dei percorsi di 80 byte, più 128 byte di overhead per ogni voce, richiede all’incirca 832 KB Memoria nella cache di Realpath; come riserva prevedo 4 MiB o più. Se il codice cresce in modo significativo a causa di plugin o moduli, lo scalo in modo lineare e ricontrollo il Colpi rispetto agli errori. Sui server in shared hosting prendo inoltre in considerazione i limiti degli inode, poiché un numero eccessivo di file di piccole dimensioni appesantisce l’intero sistema; a tal fine mi è d’aiuto questa panoramica su Limiti degli inode. È meglio prevedere un margine di sicurezza piuttosto che operare costantemente al limite. In questo modo riduco il numero di chiamate di sistema senza consumare inutilmente RAM.

In breve: il mio programma di messa a punto

Per prima cosa misuro il numero di file per ogni richiesta, poi imposto un valore adeguato Dimensione della cache e una che si adatti alle pratiche di implementazione TTL. Successivamente controllo il carico con realpath_cache_get()/size(), lo regolo gradualmente e combino il tutto con una messa a punto di OPcache e della cache del sistema operativo. Durante i rollout dei collegamenti simbolici mantengo il TTL breve o riavvio FPM, mentre negli ambienti statici utilizzo tempi di vita lunghi. L’obiettivo rimane un elevato tasso di hit della cache senza sprechi di RAM. In questo modo traggo dalla cache Realpath un “turbo” spesso sottovalutato per garantire prestazioni PHP costanti.