Cache Realpath do PHP: um impulsionador subestimado para o desempenho do PHP

A funcionalidade, muitas vezes ignorada, que permite pedidos PHP rápidos chama-se PHP Realpath Cache: Armazena os caminhos resolvidos na memória e reduz as consultas dispendiosas ao sistema de ficheiros nas instruções «include» e «require». Em projetos com Symfony, Laravel ou uma configuração de grande dimensão do WordPress, consigo aumentar, com uma configuração adequada do Realpath, a Desempenho mensurável e mantenho o número de chamadas de sistema por pedido significativamente mais baixo.

Pontos centrais

• Mais simples Hebel: O Realpath armazena as resoluções de caminho e reduz os acessos ao sistema de ficheiros.
• Por trabalhador: Cada processo PHP-FPM mantém o seu próprio cache Realpath.
• Tamanho A ter em conta: uma cache demasiado pequena provoca thrashing e atrasa os pedidos.
• TTL determina a atualização: TTL longo para implementações estáveis, curto para ligações simbólicas/segredos.
• Monitorização: As funções realpath_cache_get() e size() mostram a utilização e as lacunas.

O que o cache do Realpath faz exatamente

Sempre que se utiliza «include», «require» ou «file_get_contents», o PHP converte os caminhos relativos em caminhos absolutos e guarda esses resultados no Cache. Se o mesmo caminho voltar a surgir, leio o resultado da memória e poupo-me à dispendiosa ida ao sistema de ficheiros. Este mecanismo reduz significativamente as chamadas ao sistema, sobretudo quando o autoloading do Composer carrega muitas classes e ficheiros de configuração. Importante: o cache Realpath existe por processo; por isso, cada worker do PHP-FPM só beneficia deste mecanismo após algumas solicitações, quando já tiver criado o seu próprio cache. Desta forma, cria-se um efeito de aceleração contínuo, que se revela particularmente vantajoso em condições de carga elevada.

Por que é que a cache é importante em grandes frameworks

Os grandes frameworks e os muitos plugins geram inúmeros por cada pedido Acessos aos ficheiros, que, sem o cache, teriam de resolver os caminhos de novo todas as vezes. Se o cache do Realpath for demasiado pequeno, este substitui as entradas mais antigas, são adicionadas novas entradas e eu observo puro Bater. O resultado são operações repetidas de estatísticas e pesquisa, que consomem tempo e sobrecarregam as E/S. Na prática, isto permite reduzir o número de chamadas de sistema por pedido em cerca de 5–15 %, o que, com uma taxa elevada de pedidos, acaba por ter um impacto significativo. Quanto mais modular for a aplicação, maior será o impacto positivo de um cache Realpath devidamente dimensionado.

É assim que determino o tamanho adequado da cache

Primeiro, conto os percursos únicos de um pedido típico, calculo o comprimento médio do percurso e somo cerca de 128 bytes por entrada Despesas gerais. A partir do número, do comprimento do caminho e da sobrecarga, calculo um realpath_cache_size que seja suficiente Tampão oferece. Muitos projetos de maior dimensão ficam entre 4 e 16 MiB, e os monorepos muito extensos podem ultrapassar esse valor. É importante que a cache não fique sempre no limite, caso contrário, perco a vantagem por ter de a esvaziar constantemente. Aumento o tamanho gradualmente, observo a utilização e ajusto em conformidade.

Configurações recomendadas e valores de exemplo

Os valores predefinidos datam de uma época em que as bases de código eram pequenas e, muitas vezes, já não se adequam às atuais Configurações. Para muitas aplicações produtivas, defino o `realpath_cache_size` entre 4096K e 16384K e aumente o `realpath_cache_ttl` para 360–600 Segundos ou mais. Os fatores decisivos são a dimensão do projeto, a frequência de implementação e as características do sistema de ficheiros. A tabela seguinte apresenta valores de referência úteis para orientação e ajuda a dar os primeiros passos no ajuste. Posteriormente, ajusto os valores com base na monitorização e nos testes de carga.

Definição	Incumprimento frequente	Bons valores iniciais	Efeito esperado
tamanho_da_cache_do_caminho_real	4096K (4 MiB)	4096K–16384K	Reduzido Bater no caso de muitos ficheiros
realpath_cache_ttl	120–600 s	360–900 s	Mais longas Paragens de cache, menos novas dissoluções

Exemplos no ficheiro php.ini: realpath_cache_size = 4096K e para grandes frameworks realpath_cache_size = 16384K. No que diz respeito à durabilidade, costumo usar realpath_cache_ttl = 360 ou superior, no caso de lançamentos raros. Desta forma, os percursos permanecem na memória ao longo de muitas solicitações, sem serem constantemente revalidados.

Escolher o TTL de forma inteligente – consoante a implementação

O TTL adequado depende em grande medida do processo de implementação e da utilização de Links simbólicos . Quando alterno entre versões através da rotação de links simbólicos, o cache não pode apresentar caminhos desatualizados; por isso, defino o TTL para um valor curto ou provooco um reinício do FPM após o Lançamento. Em ambientes Kubernetes que utilizam Secrets ou ConfigMaps como volumes, reduzo significativamente o TTL ou desativo temporariamente o Realpath Cache. Por outro lado, as situações de alojamento web mais estáticas beneficiam de TTLs mais longos, uma vez que os caminhos raramente se alteram. É assim que consigo equilibrar a atualidade e a velocidade de acordo com o ambiente.

Monitorizar e verificar

Verifico regularmente com realpath_cache_get(), quais os caminhos no Cache estão, e com realpath_cache_size(), quanto espaço de armazenamento está ocupado. Se a utilização estiver próxima do tamanho configurado, aumentei o Capacidade Gradualmente. Se a cache ficar cheia muito rapidamente, interpreto isso como um sinal de que é necessário mais memória ou de que o TTL é demasiado curto. Após instalações de plugins de maior dimensão ou atualizações do framework, verifico novamente. Só quem conhece os números consegue tomar decisões sensatas em matéria de otimização.

Impacto mensurável: como medir chamadas de sistema e latências

Para garantir que o ajuste seja robusto, faço medições antes e depois das alterações. No Linux, registo as chamadas ao sistema de ficheiros por pedido com estirpe ou perfeito, quer num único worker FPM, quer na CLI.

• Pedido único (CLI): strace -c -o /tmp/strace.txt php public/index.php apresenta uma visão geral do número de stat(), openat() e lstat() incorrer.
• Anexar o FPM-Worker: strace -fp -e trace=file -o /tmp/strace-fpm.log mostra apenas as chamadas relacionadas com ficheiros. Anteriormente, com ps determinar o PID do worker.
• Ensaio de carga: Com ferramentas como de ou olá Simulo uma carga e comparo as latências P95/P99 com diferentes tamanhos de cache.

Paralelamente, faço com que o PHP me mostre o estado da cache, por exemplo, num endpoint de depuração ou através da CLI:

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

É assim que percebo se o aumento do tamanho_da_cache_do_caminho_real reduz efetivamente os erros e as chamadas ao sistema de ficheiros, em vez de se limitar a ocupar memória RAM. Idealmente, a taxa de acertos aumenta, enquanto as latências P95 diminuem sensivelmente.

É assim que eu pré-carrego o cache do Realpath de forma seletiva

Como a cache é criada por cada trabalhador, vale a pena um Aquecimento após a implementação ou o reinício. O objetivo é que os includes mais frequentes sejam armazenados no cache logo no início, antes de chegar o tráfego real dos utilizadores.

• Repetições de pedidos: Após a implementação, executo automaticamente uma série de URLs típicas (front-end, administração, API).
• Inicialização da CLI: Um pequeno script de inicialização carrega os percursos centrais (autoloader, kernel, configuração, rotas).

<?php
// warmup.php
require __DIR__.'/vendor/autoload.php';  // Composer
require __DIR__.'/config/bootstrap.php'; // Depende do projeto
require __DIR__.'/public/index.php';     // Controlador frontal (pode desencadear uma execução curta)
echo sprintf("Entradas %d preparadas, %d bytes utilizados\n",
    count(realpath_cache_get()), realpath_cache_size());

Embora este aquecimento não abranja todas as solicitações reais, ele armazena os percursos mais utilizados e encurta sensivelmente a fase inicial de arranque a frio de cada worker.

Interação com o OPcache e a cache do sistema de ficheiros

O OPcache acelera a execução de ficheiros PHP, enquanto o Realpath encurta o caminho até ao ficheiro; por isso, combino os dois Técnicas. Para as configurações do OPcache, utilizo valores comprovados e remeto para fontes fiáveis Otimização do OPcache, para que o bytecode e os caminhos funcionem em perfeita sintonia. Além disso, o Realpath beneficia de uma cache «quente» do sistema operativo, que fornece rapidamente pesquisas de diretórios e metadados. Desta forma, evito tempos de espera duplicados durante o carregamento e a análise. Quem coordenar ambos os níveis consegue ganhos percetíveis no tempo de resposta.

Tirar o máximo partido do carregamento automático do Composer

O Composer-Autoloader é um dos principais responsáveis pela resolução de percursos. Quanto mais determinístico for o seu funcionamento, mais fácil será o trabalho do Realpath Cache.

• Otimizar o Classmap: composer dump-autoload -o reduz as verificações de diretórios e as pesquisas repetidas.
• Manter o Autoload em modo estritoCom classmap-autoritário (Configuração do projeto) evito recuos desnecessários, que, de outra forma, provocariam resoluções de caminho adicionais.
• Organizar a estrutura: Hierarquias de pastas planas e consistentes e poucos casos especiais (por exemplo, includes que abrangem vários módulos ou clientes) estabilizam a carga do cache.

O resultado: menos percursos distintos por pedido, maior reutilização na cache do Realpath e, consequentemente, menores custos de E/S.

FPM e orçamento de memória: o que é realista por trabalhador

Como a cache do Realpath existe por processo, o tamanho configurado multiplica-se pelo número de workers do FPM. Por isso, estou a planear um orçamento:

• Exemplo: 12 workers × 8 MiB = 96 MiB de «Realpath-Kopf»; a isto acrescem a OPcache, o heap do PHP e a sobrecarga das extensões.
• Equilibrar: Se o OPcache tiver espaço suficiente, o Realpath pode receber mais alguns MiB – ou vice-versa.
• Específico para piscinas: Os diferentes conjuntos de FPM (Front, Admin, API) podem ter tamanhos de Realpath distintos, em função da respetiva pegada de código.

À medida que o código cresce a cada lançamento, cresce também o tamanho_da_cache_do_caminho_real-normalmente acompanha a procura. Por isso, verifico regularmente a ocupação máxima sob carga, e não apenas em regime de inatividade.

Casos especiais: ligações simbólicas, contentores e NFS

Nos lançamentos de links simbólicos, faço uma breve TTL ou reinicie o FPM após a implementação, para que todos os workers carreguem os caminhos atualizados. Em contentores com volumes mutáveis, tenho o cuidado de garantir que a cache não fique desatualizada Objectivos ajusto o TTL. No NFS, recomenda-se ainda uma estratégia de OPcache bem definida e o mínimo possível de mudanças de diretório. Se os caminhos mudarem durante a execução, em caso de dúvida, esvazio de forma seletiva com clearstatcache(true) incluindo a parte do Realpath. Regras de implementação claras evitam situações de inconsistência entre os trabalhadores.

Dificuldades e limites típicos

Como a cache existe por processo, cada um tem de Trabalhador Em primeiro lugar, é necessário recolher os caminhos antes de o efeito entrar em vigor. Em configurações com restrições rigorosas do open_basedir, a cache do Realpath funciona de forma limitada, pelo que tenho isso em conta Limites na fase de planeamento. Caches demasiado pequenas provocam thrashing, enquanto caches demasiado grandes desperdiçam RAM – procuro o ponto máximo da curva através de medições. Além disso, tenho em conta que o Realpath não é um cache de metadados ou de conteúdo, mas armazena exclusivamente resoluções de caminhos. Quem tem expectativas erradas acaba por ignorar causas que se encontram noutros locais.

Segurança operacional: falhas típicas e verificações rápidas

Alguns sintomas indicam claramente problemas com o Realpath – e podem ser rapidamente verificados:

• Latências instáveis após a implementação: Ou um TTL demasiado longo na rotação dos links simbólicos, ou falta de aquecimento. Solução: TTL curto, reinício do FPM e, em seguida, priming.
• Muitas repetidas stat()-VisualizaçõesCom estirpe visível; muitas vezes, o tamanho da cache é demasiado pequeno ou determinados caminhos dinâmicos substituem as entradas ativas.
• Grande variação entre os trabalhadores: Caches diferentes por processo. Solução: aquecimento consistente e distribuição uniforme das solicitações.

Muitas vezes, basta uma verificação rápida do estado do sistema através de PHP:

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

É assim que consigo ver se são sobretudo as pastas (muitos módulos, estruturas de fornecedores) ou os ficheiros (inúmeras configurações/classes) que dominam a cache – e ajusto a estrutura ou o tamanho em conformidade.

Cache de estatísticas vs. cache de caminho real: distinguir deliberadamente

Além da cache Realpath, o PHP também mantém uma Stat-Cache para resultados de stat() e chamadas relacionadas. Ambos os caches podem ser acedidos através de clearstatcache() influenciar:

• clearstatcache() esvazia a cache de estatísticas (opcional para um ficheiro específico).
• clearstatcache(true) esvazia também a cache do Realpath.

Em casos raros – por exemplo, no caso de workers CLI de execução prolongada com montagens dinâmicas ou em hot-swaps – utilizo um clearstatcache(true)-Hook após alterações conhecidas. Caso contrário, deixo o TTL funcionar e evito invalidações desnecessárias.

Verificação prática para ambientes de alojamento

Primeiro, determino a dimensão do projeto, ou seja, quantos ficheiros uma solicitação típica carrega, e, em seguida, verifico a carga do Caches. Em seguida, escolho um valor para `realpath_cache_size` que abranja todos os caminhos utilizados com frequência, além de uma reserva, e defino um TTL que se adapte aos ritmos de implementação. Depois, observo os efeitos através da monitorização e dos registos e ajusto os valores com cuidado, em vez de os aumentar de forma brusca. Além disso, vale a pena dar uma vista de olhos na cache do sistema operativo, por exemplo, na configuração do Linux Pressão da cache VFS, porque o Realpath beneficia de pesquisas rápidas nos diretórios. É assim que vou introduzindo melhorias, sem deixar escapar efeitos colaterais.

Âmbito e vias de configuração: onde definir cada valor

Dependendo do ambiente, atualizo os parâmetros em locais diferentes:

• Mundial: php.ini para as predefinições a nível do sistema.
• Pro-Pool: Nos pools FPM por php_admin_value[realpath_cache_size] e php_admin_value[realpath_cache_ttl] dimensionar de forma específica para o front-end e a API.
• Diretório Pro: Em .user.ini (se permitido), útil em ambientes de alojamento partilhado.

Importante: Alterações à php.ini e as configurações do FPM Pool exigem um reinício ou uma atualização para que os workers sejam iniciados com os novos valores.

CLI, Queue-Worker e tarefas Cron: as mesmas regras, tempos de execução diferentes

Os scripts CLI e os workers da fila também beneficiam da cache Realpath – no entanto, a Vida útil muitas vezes diferente:

• Tarefas CLI de curta duração: O cache é recriado a cada chamada. Neste caso, o aquecimento e um TTL elevado têm pouca utilidade; o mais importante é que o cache tenha um tamanho suficiente para que as inclusões repetidas no próprio trabalho sejam armazenadas no cache.
• Daemons/Workers: Os processos de execução prolongada (Supervisor, Systemd) criam uma cache estável. Após um Recarregar código (Deploy) o processo deve ser reiniciado; caso contrário, poderão permanecer caminhos desatualizados na cache.

Avaliar a dimensão dos projetos e o efeito de armazenamento

Uma aplicação com 4000 percursos únicos e 80 bytes de comprimento de percurso, mais 128 bytes de sobrecarga por entrada, ocupa, aproximadamente, 832 KB Memória na cache do Realpath; como margem de segurança, prevejo 4 MiB ou mais. Se a base de código crescer significativamente devido a plug-ins ou módulos, adapto a capacidade de forma linear e volto a verificar a Acertos versus erros. Em servidores partilhados, presto também atenção aos limites de inodes, porque um número excessivo de ficheiros pequenos sobrecarrega todo o sistema; para isso, esta visão geral ajuda-me a Limites de inodes. É melhor contar com uma margem de segurança do que funcionar constantemente no limite. Assim, poupo chamadas ao sistema sem consumo desnecessário de RAM.

Em poucas palavras: o meu plano de tuning

Primeiro, conto o número de ficheiros por pedido e, depois, defino um valor adequado Tamanho da cache e uma que se adapte à prática de implementação TTL. Em seguida, verifico a carga com realpath_cache_get()/size(), faço ajustes graduais e combino tudo isto com ajustes finos no OPcache e na cache do sistema operativo. Em implementações de links simbólicos, mantenho o TTL curto ou reinicio o FPM; em ambientes estáticos, utilizo tempos de vida longos. O objetivo continua a ser uma elevada taxa de acertos no cache sem desperdício de RAM. É assim que tiro partido do Realpath Cache como um «turbo» subestimado para um desempenho consistente do PHP.