Кеширование — (Как) работает PHP кеш скрипта и пользовательских INI-файлов?

Question

Кеширование — (Как) работает PHP кеш скрипта и пользовательских INI-файлов?

В настоящее время я храню конфигурацию для моих сценариев PHP в переменных и константах в другом сценарии PHP (например, config.php).

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

По моему мнению, PHP хранит файлы сценариев в памяти, поэтому включение файла сценария (обычно) не вызывает IO (или Zend выполняет кэширование? Или источники вообще не кэшируются?).

Как это с чтением кастомных INI-файлов. Я знаю что для .user.ini есть кеширование (см. user_ini.cache_ttl), но PHP также кэширует пользовательские INI-файлы? или вызывает parse_ini_file() всегда вызывает IO?

6

caching configuration configuration-files ini php

Решение

Другие решения

parse_ini_file () использует стандартные операции для преобразования файла в массив.

0

Источник

Accepted Answer

Резюме

Время, необходимое для загрузки директив конфигурации (что не такое же, как время, необходимое приложению для выполнения этих директив) обычно незначительный — ниже одной миллисекунды для большинства конфигураций «разумного размера». Так что не волнуйтесь — INI, PHP или JSON с точки зрения производительности одинаково хороши. Даже если бы PHP был в десять раз быстрее, чем JSON, это было бы похоже на загрузку в 0,001 с вместо 0,01 с; очень немногие когда-либо заметят.

Тем не менее, там являются соображения при решении, где хранить данные конфигурации.

.INI vs .php хранилище конфигурации

Время загрузки: в основном идентично, если не задействовано кэширование (см. Ниже), и, как я уже сказал, не очень важно.
простота использования: .ini легче читать и изменять для человека. Это может быть преимуществом или недостатком (если последнее, думаю, проверка целостности).
формат данных: PHP может хранить больше структурированных данных, чем файлы .ini, если не используются действительно сложные обходные пути. Но рассмотрим возможность использования JSON вместо INI.
- Более структурированные данные означают, что вы можете легко создать «суперконфигурацию» PHP или JSON, содержащий эквивалент нескольких файлов INI, сохраняя при этом информацию в полной изоляции.
автоматический контроль избыточности: включение файла PHP может быть упрощено с помощью require_once,
Пользовательские изменения: существуют визуальные редакторы INI и JSON, которые позволяют пользователю изменять файл INI или JSON, сохраняя его, по крайней мере, синтаксически допустимым. Не так для PHP (вам нужно будет свернуть свой собственный).

Кэширование

Ядро PHP не делает кеширование. период. Тем не менее, вы никогда не будете использовать ядро PHP в одиночестве: он будет загружен как (быстрый) CGI, модуль Apache и так далее. Кроме того, вы можете не использовать установку «barebone», но вы можете иметь (есть вероятность, что вы будут есть) установлено несколько модулей.

Как часть загрузчика, так и часть модуля могут выполнять кэширование; и оба этих действия могут привести к ненужным дублированиям или конфликтам, поэтому стоит проверить это:

файл (но это не меняется между файлами INI, JSON и PHP) будет кэшироваться на уровне подсистемы ввода-вывода файловой системы, и, если память действительно не требует больших затрат, он будет загружен оттуда (на соответствующем примечании это одна из причин, почему не все файловые системы одинаково хороши для всех сайтов).
если вам нужна конфигурация в нескольких файлах, и используйте require_once во всех из них конфигурация будет загружена только один раз, как только она потребуется. Это не кэширование, но, тем не менее, улучшение производительности.
существует несколько модулей (Zend, opcache, APC, …), которые будут кешировать все PHP файлы, конфигурация включена. Они не будут кэшировать INI-файлы.
кэширование, выполняемое модулями (например, opcache), может (а) игнорировать дальнейшие изменения файловой системы, что означает, что после изменения файла PHP вам необходимо каким-то образом перезагрузить или аннулировать кэш; как это сделать, меняется от модуля к модулю; (b) реализовать ярлыки, которые могут конфликтовать с управлением данными файловой системы или ее файловой структурой (как известно, opcache может игнорировать часть пути к файлу, что позволяет гораздо быстрее если у вас нет двух файлов с одинаковыми именами в разных каталогах, когда он рискует загрузить один вместо другого).

Повышение производительности: кеш переваренный данные вместо директив конфигурации

Довольно часто бывает так, что в зависимости от какой-либо директивы config вам придется выполнять одну из нескольких нетривиальных операций. Затем вы будете использовать результаты для фактического вывода.

Что замедляет рабочий процесс в этом случае, так это не чтение, скажем, «config.layout» «VERTICAL» или «HORIZONTAL», но на самом деле генерирует макет (или что-то еще). В этом случае вы можете получить огромные преимущества, храня сгенерированный объект где-то:

сериализованный внутри файла (например, cache/config.layout.vertical.html.gz). Вам, вероятно, потребуется развернуть какую-то «проверку устаревших данных», если меняется макет, или какую-то процедуру аннулирования кэша. (Для макетов, в частности, вы можете проверить прут, который также делает параметризованное кэширование шаблона).
внутри хранилища ключей, такого как Redis.
в базе данных RDBMS, такой как MySQL (даже если это излишне — вы будете использовать ее в основном как хранилище ключей).
более быстрые альтернативы NoSQL, такие как MongoDB.

Дополнительные опции

Вы, вероятно, захотите прочитать о кэширование клиента и заголовки, и, возможно, изучите любые варианты, которые предлагает ваш хостинг (балансировщики нагрузки, HTTP-кэши, такие как Varnish и т. д.).

5