Кэширование кода операции 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 и т. д.), а затем создав реальный путь из этой сокращенной формы создают уникальный идентификатор.Есть только один и тот же путь, а не два.

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

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

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

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

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

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

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

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

1. Многие люди утверждают, что могут ускорить любое приложение с помощью __автозагрузка.
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 приходится выполнять больше работы под водой.по крайней мере, еще одна потенциальная ошибка, к которой нужно подготовиться и обработать, и многое другое, что нужно сделать, если требуемый файл не существует.