Кэширование PHP Opcode / Zend Acceleration и include_once vs. require_once

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

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

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

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

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

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

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

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

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

    Это просто сложно найти иначе. 🙂

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

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

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

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

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

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

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

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