Кэш PHP Realpath: недооцененный ускоритель производительности PHP

Часто упускаемый из виду механизм для ускорения запросов PHP называется PHP Realpath Кэш: он сохраняет разрешенные пути в оперативной памяти и сокращает количество ресурсоемких запросов к файловой системе при использовании include/require. В проектах на Symfony, Laravel или в крупных установках WordPress я повышаю производительность с помощью правильной настройки Realpath Производительность измеримо и позволяет значительно сократить количество системных вызовов на каждый запрос.

Центральные пункты

• Проще Hebel: Realpath сохраняет результаты преобразования путей и сокращает количество обращений к файловой системе.
• На одного работника: Каждый процесс PHP-FPM ведёт свой собственный кэш Realpath.
• Размер Важно: слишком маленький кэш приводит к перегрузке и замедлению обработки запросов.
• TTL определяет степень актуальности: длительный TTL для стабильных развертываний, короткий — для символьных ссылок и секретных данных.
• Мониторинг: функции realpath_cache_get() и size() показывают загрузку и пробелы.

Что именно делает кэш Realpath

При каждом вызове функций `include`, `require` или `file_get_contents` PHP преобразует относительные пути в абсолютные и сохраняет результаты в Кэш. Если этот же путь поступает снова, я считываю результат из памяти и избавляюсь от необходимости выполнять ресурсоемкий вызов в файловая система. Этот механизм заметно сокращает количество системных вызовов, особенно когда автозагрузка Composer загружает большое количество классов и конфигурационных файлов. Важно: кэш Realpath существует для каждого процесса, поэтому каждый рабочий процесс PHP-FPM начинает получать выгоду только после нескольких запросов, когда он сформирует собственный кэш. Таким образом, создается постоянный эффект ускорения, который особенно окупается при высокой нагрузке.

Почему кэш играет важную роль в крупных фреймворках

Крупные фреймворки и множество плагинов генерируют на каждый запрос бесчисленное количество Обращения к файлам, которым без кэширования пришлось бы каждый раз заново определять пути. Если кэш Realpath слишком мал, он вытесняет старые записи, добавляются новые, и я наблюдаю чистое Thrashing. В результате возникают повторяющиеся операции статистики и поиска, которые отнимают время и создают нагрузку на ввод-вывод. На практике это позволяет снизить количество системных вызовов на один запрос примерно на 5–15 %, что при высокой частоте запросов дает значительный эффект. Чем модульнее приложение, тем больше эффект от правильно рассчитанного кэша Realpath.

Вот как я определяю подходящий размер кэша

Сначала я подсчитываю количество уникальных путей в типичном запросе, оцениваю среднюю длину пути и прибавляю примерно 128 байт на каждую запись Накладные. На основании количества, длины пути и накладных расходов я вычисляю величину realpath_cache_size, которая должна быть достаточной Буфер предлагает. Многие крупные проекты занимают от 4 до 16 MiB, а очень объёмные монорепозитории — даже больше. Важно, чтобы кэш не достигал предельной загрузки, иначе я теряю преимущество из-за постоянной очистки. Я увеличиваю объём постепенно, слежу за загрузкой и корректирую настройки по мере необходимости.

Рекомендуемые настройки и примерные значения

Стандартные значения появились в эпоху небольших кодовых баз и зачастую уже не соответствуют современным требованиям Установки. Для многих рабочих приложений я устанавливаю значение realpath_cache_size в диапазоне от 4096K до 16384K и увеличиваю значение realpath_cache_ttl до 360–600 Секунды или более. Решающими факторами являются размер проекта, частота развертывания и особенности файловой системы. В приведённой ниже таблице представлены ориентировочные значения, которые помогут вам сориентироваться и приступить к настройке. Затем я корректирую эти значения на основе данных мониторинга и результатов нагрузочных тестов.

Настройка	Частые случаи неисполнения обязательств	Хорошие начальные показатели	Ожидаемый эффект
realpath_cache_size	4096K (4 МБ)	4096K–16384K	Снижение Thrashing при большом количестве файлов
realpath_cache_ttl	120–600 с	360–900 с	Более длительные Остановки кэша, меньше повторных роспусков

Примеры в файле php.ini: realpath_cache_size = 4096K и для крупных фреймворков realpath_cache_size = 16384K. В повседневной жизни я часто использую realpath_cache_ttl = 360 или выше в случае редких обновлений. Таким образом, пути сохраняются в памяти на протяжении множества запросов, не подвергаясь постоянной повторной проверке.

Правильно выбрать TTL — в зависимости от сценария развертывания

Правильное значение TTL в значительной степени зависит от процесса развертывания и использования Symlinks . Когда я переключаюсь между версиями с помощью ротации символьных ссылок, кэш не должен возвращать устаревшие пути, поэтому я устанавливаю короткий срок TTL или запускаю перезапуск FPM после Развернуть. В средах Kubernetes, где в качестве томов используются секреты (Secrets) или ConfigMaps, я значительно сокращаю время жизни (TTL) или временно отключаю кэш Realpath. В то же время в более статичных условиях веб-хостинга целесообразно использовать более длительные значения TTL, поскольку пути редко меняются. Таким образом я нахожу баланс между актуальностью и скоростью в зависимости от конкретной среды.

Мониторинг и проверка

Я регулярно проверяю с помощью realpath_cache_get(), какие пути в Кэш находятся, и с realpath_cache_size(), сколько места из этого объёма уже занято. Если использование приближается к настроенному размеру, я увеличиваю Вместимость Поэтапно. Если кэш заполняется чрезвычайно быстро, я рассматриваю это как сигнал о необходимости увеличения объёма памяти или о слишком коротком значении TTL. После установки крупных плагинов или обновлений фреймворка я проверяю ситуацию заново. Только зная цифры, можно принимать обоснованные решения по настройке.

Измеримый эффект: как я измеряю системные вызовы и задержки

Чтобы убедиться в надежности настройки, я провожу измерения до и после внесения изменений. В Linux я фиксирую количество вызовов файловой системы на каждый запрос с помощью strace или перфект, по выбору — на отдельном рабочем процессе FPM или в командной строке.

• Отдельный запрос (CLI): strace -c -o /tmp/strace.txt php public/index.php содержит обзор того, сколько stat(), openat() и lstat() возникают.
• Добавить работника FPM: strace -fp -e trace=file -o /tmp/strace-fpm.log отображает только вызовы, связанные с файлами. Ранее с помощью ps определить PID рабочего процесса.
• Испытание нагрузкой: С помощью таких инструментов, как с сайта или привет Я моделирую нагрузку и сравниваю задержки P95/P99 при разных размерах кэша.

Параллельно с этим я вывожу информацию о загрузке кэша из PHP, например, в конечной точке отладки или через CLI:

<?php
$entries = realpath_cache_get();
$size    = realpath_cache_size();
printf("Записей: %d, Использовано: %d байт (%.2f MiB)\n", count($entries), $size, $size/1048576);

Так я могу определить, приведет ли повышение realpath_cache_size фактически снижает количество промахов и вызовов файловой системы, а не просто занимает ОЗУ. В идеале частота попаданий увеличивается, а задержки P95 заметно сокращаются.

Вот как я целенаправленно прогреваю кэш Realpath

Поскольку кэш создаётся для каждого рабочего процесса, имеет смысл Разминка после развертывания или перезапуска. Цель состоит в том, чтобы наиболее часто используемые файлы include попадали в кэш на раннем этапе, до появления реального пользовательского трафика.

• Повторы запросов: После развертывания я автоматически тестирую несколько типичных URL-адресов (фронтенд, админ-панель, API).
• Подготовка CLI: Короткий скрипт автозагрузки загружает основные пути (автозагрузчик, ядро, конфигурацию, маршруты).

<?php
// warmup.php
require __DIR__.'/vendor/autoload.php';  // Composer
require __DIR__.'/config/bootstrap.php'; // Зависит от проекта
require __DIR__.'/public/index.php';     // Фронт-контроллер (может запускать короткий цикл)
echo sprintf("Подготовлено %d записей, использовано %d байтов\n",
    count(realpath_cache_get()), realpath_cache_size());

Хотя эта подготовка и не охватывает все реальные запросы, она сохраняет наиболее часто используемые пути и заметно сокращает начальную фазу «холодного запуска» для каждого рабочего процесса.

Взаимодействие с OPcache и кэшем файловой системы

OPcache ускоряет выполнение PHP-файлов, а Realpath сокращает путь к файлу, поэтому я использую их вместе Техника. Для настроек OPcache я использую проверенные значения и ссылаюсь на авторитетные Оптимизация OPcache, чтобы байт-код и пути идеально взаимодействовали друг с другом. Кроме того, Realpath использует «теплый» кэш ОС, который быстро предоставляет результаты поиска в каталогах и метаданные. Таким образом, я избегаю двойного времени ожидания при загрузке и при разборе. Координация обоих уровней позволяет добиться заметного сокращения времени отклика.

Оптимальное использование автозагрузки Composer

Автозагрузчик Composer является основным механизмом, отвечающим за разрешение путей. Чем более детерминированно он работает, тем проще работает кэш Realpath.

• Оптимизировать карту классов: composer dump-autoload -o сокращает количество сканирований каталогов и повторных запросов.
• Строго соблюдать автозагрузкуС classmap-authoritative (Настройки проекта) я избегаю ненужных резервных вариантов, которые в противном случае приводят к дополнительному разрешению путей.
• Упорядочить структуру: Плоская и однородная иерархия папок, а также небольшое количество особых случаев (например, включения, охватывающие несколько модулей или клиентов) способствуют стабилизации нагрузки на кэш.

Результат: меньшее количество различных путей на один запрос, более широкое повторное использование данных в кэше Realpath и, как следствие, снижение затрат на ввод-вывод.

FPM и бюджет памяти: что реально для одного рабочего процесса

Поскольку кэш Realpath существует для каждого процесса, настроенный размер умножается на количество рабочих процессов FPM. Поэтому я планирую следующий бюджет:

• Пример: 12 рабочих процессов × 8 MiB = 96 MiB «Realpath-Kopf»; к этому добавляются OPcache, куча PHP и накладные расходы расширений.
• Балансировка: Если у OPcache достаточно свободного места, Realpath может получить на несколько MiB больше — или наоборот.
• Специфично для бассейна: Различные пулы FPM (Front, Admin, API) могут иметь разный размер Realpath в зависимости от объёма соответствующего кода.

Если объем кода увеличивается с каждым выпуском, то увеличивается и realpath_cache_size-потребность, как правило, растет. Поэтому я регулярно проверяю пиковую загрузку не только в режиме простоя, но и при нагрузке.

Особые случаи: символьные ссылки, контейнеры и NFS

При развертывании символьных ссылок я составляю краткую TTL или перезапустите FPM после развертывания, чтобы все рабочие процессы загрузили обновленные пути. В контейнерах с изменяемыми томами я слежу за тем, чтобы кэш не содержал устаревших Цели регулирую TTL. При использовании NFS рекомендуется также применять грамотную стратегию OPcache и по возможности минимизировать количество переходов между каталогами. Если пути меняются во время выполнения, в случае сомнений я целенаправленно очищаю с помощью clearstatcache(true) в том числе и часть Realpath. Четкие правила развертывания предотвращают возникновение несогласованных состояний между рабочими узлами.

Типичные препятствия и ограничения

Поскольку кэш существует для каждого процесса, каждый Рабочий Прежде всего, нужно собрать пути, прежде чем эффект начнёт действовать. В конфигурациях с жесткими ограничениями open_basedir кэш Realpath работает с ограничениями, поэтому я учитываю это Границы при планировании. Слишком маленькие кэши приводят к трэшингу, слишком большие — к растрате оперативной памяти — я ищу пик кривой с помощью измерений. Кроме того, я обращаю внимание на то, что Realpath не является кэшем метаданных или контента, а хранит исключительно результаты разрешения путей. Те, кто питает ложные ожидания, упускают из виду причины, лежащие в других областях.

Эксплуатационная безопасность: типичные неисправности и быстрая диагностика

Некоторые симптомы явно указывают на проблемы с Realpath — и их можно быстро проверить:

• Нестабильные задержки после развертывания: Либо слишком длительный TTL при ротации символьных ссылок, либо отсутствует прогрев. Решение: установить короткий TTL, перезапустить FPM, а затем выполнить прогрев.
• Многократные stat()-просмотровС strace заметно; часто размер кэша слишком мал, либо определённые динамические пути вытесняют «горячие записи».
• Высокая дисперсия между рабочими узлами: Различные кэши для каждого процесса. Решение: последовательная подготовка и равномерное распределение запросов.

Часто достаточно быстрого проверки работоспособности с помощью PHP:

<?php
$entries = realpath_cache_get();
$byDir = 0; $byFile = 0;
foreach ($entries as $e) { $e['is_dir'] ? $byDir++ : $byFile++; }
printf("Каталоги: %d, файлы: %d, использовано: %.2f MiB\n", $byDir, $byFile, realpath_cache_size()/1048576);

Так я могу определить, что в кэше преобладают в основном каталоги (множество модулей, структуры поставщиков) или файлы (многочисленные конфигурации/классы), — и соответствующим образом скорректировать структуру или размер.

Stat-Cache и Realpath-Cache: сознательное разграничение

Помимо кэша Realpath, PHP также ведет Stat-Cache для результатов по stat() и связанных с ними вызовах. Оба кэша можно clearstatcache() влиять на:

• clearstatcache() очищает кэш статистики (опционально для конкретного файла).
• clearstatcache(true) дополнительно очищает кэш Realpath.

В редких случаях — например, при работе долгоиспользуемых CLI-процессов с динамическими монтировками или при «горячей» замене — я использую целенаправленный clearstatcache(true)-Hook после известных изменений. В остальных случаях я позволяю TTL работать и избегаю ненужных аннулирований.

Практическая проверка хостинговых сред

Сначала я определяю размер проекта, то есть количество файлов, загружаемых в типичном запросе, а затем проверяю загрузку Кэши. Затем я выбираю значение realpath_cache_size, которое вмещает все часто используемые пути плюс резерв, и устанавливаю TTL, соответствующий частоте развертываний. После этого я отслеживаю результаты с помощью систем мониторинга и журналов и осторожно корректирую значения, а не увеличиваю их резко. Кроме того, стоит обратить внимание на кэш ОС, например, на настройку в Linux Давление кэша VFS, поскольку Realpath использует преимущества быстрого поиска каталогов. Таким образом, я внедряю улучшения, не упуская побочных эффектов.

Область применения и способы настройки: где и какие значения устанавливать

В зависимости от среды я настраиваю параметры в разных местах:

• Глобальная: php.ini для системных значений по умолчанию.
• Pro-Pool: В пулах FPM по php_admin_value[realpath_cache_size] и php_admin_value[realpath_cache_ttl] специально подбирать размеры для фронтенда и API.
• Каталог Pro: В .user.ini (если это разрешено), что целесообразно в условиях виртуального хостинга.

Важно: изменения в php.ini а конфигурации FPM-Pool требуют перезапуска или перезагрузки, чтобы рабочие процессы запустились с новыми настройками.

CLI, Queue-Worker и задания Cron: одни и те же правила, разные интервалы выполнения

Скрипты CLI и рабочие процессы очереди также используют преимущества кэша Realpath — однако Срок службы часто по-другому:

• Кратковременные задания CLI: Кэш создается заново при каждом вызове. В данном случае «разгон» и большой TTL мало помогут; гораздо важнее обеспечить достаточный размер, чтобы повторяющиеся включения в самом задании кэшировались.
• Демоны/рабочие процессы: Долгоиграющие процессы (Supervisor, Systemd) формируют стабильный кэш. После Перезагрузка кода (Deploy) процесс должен перезапуститься, иначе в кэше могут остаться устаревшие пути.

Оценка масштабов проекта и эффект накопления

Приложение с 4000 уникальными путями и длиной пути 80 байт плюс 128 байт накладных расходов на каждую запись занимает примерно 832 КБ Память в кэше Realpath; с запасом я планирую 4 МБ или больше. Если объём кода значительно увеличивается за счёт плагинов или модулей, я масштабирую объём линейно и повторно проверяю Хиты против промахов. На серверах с виртуальным хостингом я также обращаю внимание на ограничения по инодам, поскольку слишком большое количество мелких файлов создает нагрузку на всю систему; в этом мне помогает данная сводка Ограничения на количество инодов. Лучше предусмотреть запас, чем постоянно работать на пределе возможностей. Так я экономлю системные вызовы, не расходуя лишнюю оперативную память.

Коротко и по делу: мой план по тюнингу

Сначала я измеряю количество файлов на один запрос, а затем устанавливаю соответствующее Размер кэша и соответствующую практике развертывания TTL. Затем я проверяю загрузку с помощью realpath_cache_get()/size(), постепенно корректирую настройки и сочетаю все это с тонкой настройкой OPcache и кэша ОС. При развертывании символьных ссылок я устанавливаю короткий TTL или перезапускаю FPM, а в статических средах использую длительные сроки хранения. Цель — обеспечить высокий коэффициент попадания в кэш без излишнего расхода оперативной памяти. Таким образом, я использую Realpath Cache как недооценённый «турбо-ускоритель» для стабильной производительности PHP.