Кэширование кода операции PHP / ускорение Zend и include_once против require_once

Question

У меня есть коллега, который изучает кэширование кода операции / ускорение Zend (я всегда предполагал, что это одно и то же) для нашего приложения на основе PHP. Похоже, его тесты указывают на то, что мы НЕ видим повышения производительности, если мы включаем наши (большие) библиотеки классов в require_once, но мы видим повышение производительности при использовании include_once.

Это пахнет для нас обоих подозрительно, но у меня нет времени самостоятельно проверять нашу методологию оценки, и мой коллега терпимо относится к запаху рыбы, чем я. :)

Кто-нибудь сталкивался с чем-нибудь подобным? Если нет, то подумайте о других вещах, которые могут вызвать появление увеличения производительности при переключении с include_once на require_once?

Answer 1

Для начала оба вызова (require_once и include_once) дважды проверяют, не был ли файл ранее включен.

Таким образом, они оба достигают этого путем поиска файла по всем доступным путям и, по существу, проверки, не было ли его в миксе раньше и т. Д.

В фоновом режиме происходит то, что они оценивают все различные параметры (например, несколько include_path и т. Д.), А затем, создав realpath из этой сокращенной формы, они создают уникальный идентификатор. Есть только один и тот же путь - не два.

Это уже не самый быстрый процесс на планете и обычно происходит при каждом запросе с PHP. Затем добавьте еще одну дорогую операцию, которая является stat, когда она создает то, что я назвал realpath (realpath, потому что это своего рода то, что realpath () делает), чтобы проверить, существует ли файл.

Поправьте меня, если я ошибаюсь, но у APC есть оптимизации, особенно для этого случая.

Так или иначе - теперь на разнице между require_once и include_once, которая заключается в том, что require_once оценивает файл (для низкоуровневых ошибок разбора и т. Д.), Когда он включает его , Это дополнительная проверка, от которой вы можете избавиться, если у вас достаточно QA, чтобы ошибка синтаксического анализа никогда не могла проникнуть во включаемый файл.

Просто сложно найти иное. : -)

(Что следует учесть: вы можете разработать с помощью require_once и заменить все вызовы на include_once при развертывании.)

Что касается кеша кода операции - я бы порекомендовал APC . Это обсуждалось на стеке потока раньше. Лично я / мы используем его какое-то время (мы обрабатываем примерно 100 000 посетителей в день с 3 интерфейсами и 1 сервером), и мы очень довольны. APC также оптимизирован для безумия require_once / include_once.

Довольно крутой побочный эффект заключается в том, что APC также позволяет хранить переменные PHP в памяти - своего рода постоянные и т. Д.

Пара дополнительных указателей:

1. Многие люди утверждают, что могут ускорить любое приложение с __ autoload .
2. В кеше кода операции избегайте условного require_once / include_once (например, в циклах или в потоке управления).
3. Некоторые люди говорят, что /absolute/path/to/file.php в include_ или require_once быстрее, чем полагаться на include_path.
4. Порядок путей в вашем include_path также имеет значение.

Надеюсь, это поможет.

Answer 2

Я не могу гарантировать что-либо, так как я недостаточно глубоко изучил это, но да, я видел разницу в скорости между ними. Они никогда не были достаточно значительными для меня, чтобы перейти к include_once вместо require_once.

Я всегда предполагал, что разница в том, что require_once должен выполнять больше работы под водой. по крайней мере, еще одна потенциальная ошибка, которую нужно подготовить и обработать, и еще больше, когда требуемый файл не существует.