Просто интересно, есть ли у кого-нибудь информация о том, какие «затраты» связаны с включением большого файла php (более 600 тыс. Или более), содержащего 100 файлов классов. Действительно ли это имеет большое значение по сравнению с автозагрузкой отдельных файлов, которые, например, просматривают несколько каталогов, прежде чем найти совпадение?
Будет ли кэширование APC сделать эту стоимость пренебрежимо малой?
В принципе, стоимость включения одного большого файла зависит от вашего usecase. Допустим, у вас большой файл с 200 классами.
Если вы используете только один класс, в том числе большой файл, он будет дороже, чем небольшой файл класса для этого отдельного класса.
Если вы используете все 200 классов, в том числе большой файл будет значительно дешевле, чем 200 небольших файлов.
Там, где обрезание лежит, действительно зависит от системы. Я бы понял, что это будет где-то около 50% (где, если вы используете менее 100 классов в одном запросе, автозагрузка).
И использование APC, скорее всего, сместит точку безубыточности ближе к меньшим классам (поэтому без использования 100 классов может быть точкой безубыточности, но при этом она может быть в 50 классах), поскольку она делает большой сингл включен намного дешевле, но только снижает накладные расходы каждого отдельного человека незначительно.
Точные точки безубыточности будут на 100% зависящими от системы (насколько быстро ваши дисковые операции ввода / вывода, насколько быстро ваши процессоры, сколько памяти и т. Д.). Таким образом, единственный способ узнать наверняка на вашей платформе – проверить.
Однако на карту поставлено больше, чем на сырую производительность. Поддержание работоспособности будет страдать от одного большого файла, поскольку работать с несколькими классами сложнее (вкладки в среде IDE становятся бесполезными). Я лично буду держать все классы в отдельных файлах и сделать свою жизнь проще, чем разработчик, а не сделать один гигантский монстр файла.
Теперь, если у вас есть уровень трафика на facebook, возможно, стоит исследовать его дальше. Но если вы этого не сделаете, я лично не буду беспокоиться об этом …
Я провел несколько тестов по различным расходам php include() которые я бы хотел поделиться, так как я вижу, что многие программисты или платформы CMS игнорируют эти затраты времени на предварительный запуск php.
Стоимость самой функции весьма незначительна. 100 файлов (с пустыми файлами) стоит около 5 мс; и не более одной микросекунды при использовании opcache.
Таким образом, экономия затрат на включение большего файла php, содержащего 100 классов, в отличие от 100 отдельных файлов, составляет всего около 5 мс. И использование кеша OpCode делает эту стоимость несущественной.
Реальная стоимость зависит от размера ваших файлов и того, что PHP должен анализировать и / или компилировать. Для лучшего представления о том, каковы эти затраты, приведены результаты тестов, которые я провел на Mac Mac Server 2010 года с диском 10 000 RPM с запуском PHP 5.3 с оптимизатором opcache с поддержкой eAccelerator.
1µs for 100 EMPTY File includes, w/opcache 5ms for 100 EMPTY File includes, no opcache 7ms for 100 32KB File includes, w/opcache 30ms for 100 32KB File includes, no opcache 14ms for 100 64KB File includes, w/opcache 60ms for 100 64KB File includes, no opcache 22ms for 100 128KB File includes, w/opcache 100ms for 100 128KB File includes, no opcache 38ms for 100 200KB File includes, w/opcache 170ms for 100 200KB File includes, no opcache
Таким образом, файл php 600KB примерно стоит 6 мс или около 1 мс при использовании кеша кода операции. Вместо этого вы хотите посмотреть размер всего кода, включенного в запрос.
Объединение файла в комбо, чтобы попытаться сохранить ресурсы, определенно не очень хорошая идея, и было бы ошибкой при использовании op-cache. Мой тест не учитывает скорость диска, если вообще, поскольку я включил тот же файл 100 раз. Тем не менее, я не чувствую необходимости покрывать дисковые операции ввода-вывода вообще, потому что наличие установленного операционного кэша действительно является предварительным условием с точки зрения базовой производительности.
Чтобы добиться максимальной производительности и экономии памяти, нужно сделать обратное. Для разделения файлов как можно больше, с использованием автозагрузчика или шаблона фабрики классов, для включения как можно большего количества неиспользуемого кода для каждого запроса.
Для этого неправильное использование include_once() также может иметь отрицательные последствия для производительности …
Что касается ваших базовых классов. У меня сходные обстоятельства, но я включаю только крошечную часть схемы таблицы. В основном это типы полей и детали первичного ключа. По соображениям производительности я намеренно не включаю довольно тяжелую схему таблиц все время, потому что они редко используются, и когда они есть, я использую только пару из них максимум за запрос.
Средние полные данные столбца таблицы составляют примерно 20-50 тыс. За массивы схем. В том числе 10-15 из них по любому запросу требуют около 1-3 мс для массивов. Что само по себе мало. Но это стоит того, когда в сочетании с объемом памяти 500 тыс. Памяти за запрос.
APC сэкономит вам много, но я не знаю, будет ли это незначительно, если ваш источник составляет 600 тыс. Это примерно 15000 строк кода? Не так много для веб-сайта, но довольно большой для одного файла.
Вы бы предпочли использовать более динамичный подход и специальные функции изоляции в определенных классах. Затем для каждой страницы вы можете выбрать, какой код нужен.
Особенно, когда вы используете APC, этот подход будет лучше, потому что у вас нет накладных расходов на ввод-вывод файлов, которые вы будете иметь при загрузке большого количества небольших файлов с диска. Я хотел бы реализовать небольшие, определенные классы и поместить каждый из них в отдельный файл. Вы можете использовать механизм загрузки класса PHP (__autoload) для автоматической загрузки правильных единиц.
Когда вы определяете хорошее соглашение об именах для своих классов и подразделений, это значительно упростит ваше развитие.