Является ли 148 включенных файлов слишком много

Question

Я только что заметил, что мое приложение включает в себя более 148 файлов php на одной странице. Имейте в виду, что это административный сервер, а не основной сайт, но это слишком много? Какое влияние оказывает большое количество включений на сервер, как при средней нагрузке, так и при нагрузке? Будет ли дисковый ввод-вывод проблемой?

Статистика включенных файлов

Тип файла - Количество включений - Общий размер файла

• Индекс - 1 - 0,00169 МБ
• Bootstrap - 1 - 0,01757 МБ
• Помощник - 98 - 0,58557 МБ - (11 классов, связанных с Profiler)
• Конфигурация - 8 - 0,00672 МБ
• Хранилище данных - 23 - 0,10836 МБ
• Действие - 8 - 0,02652 МБ
• Страница - 1 - 0,00094 МБ
• Ресурс I18n - 7 - 0,00870 МБ
• Библиотека поставщика - 1 - 0,02754 МБ
• Всего файлов - 148 - 0,78362 МБ

Время истекло 0,123920917511

Используемая память 2,891 МБ

---

Редактировать 1. Следует отметить, что это страница сценария наихудшего случая. У него много разных шаблонных моделей, контроллеров и связанных представлений, поскольку он обрабатывает публикации с настраиваемыми полями.

Редактировать 2. Также интерфейс имеет кэширование агрессивных страниц, поэтому число включений в передней части в данный момент составляет примерно 30-40.

Редактировать 3. Профилировщик при отключении не будет включать файлы, поэтому это значительно сократит количество включений

Answer 1

Итак, вот разбивка потенциальных проблем.

Количество файлов само по себе является проблемой. Если вы не используете кэш байт-кода (и вы его используете), и этот кэш настроен на , а не stat файл перед тем, как добавить скомпилированный байт-код, PHP будет выполнять статистику каждого из этих файлов на включите, затем прочитайте их. В некоторых случаях это также может означать разрешение пути и наивный автозагрузчик, который тыкает и подталкивает многочисленные каталоги. Это не будет «медленно», потому что ОС наверняка будет кэшировать вещи, если файлы будут часто попадать, но это добавляет драгоценные миллисекунды к каждому запросу.

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

Суть в том, что правильно настроенный кэш байт-кода полностью решит эту проблему. Нет ничего плохого в том, чтобы сказать своим клиентам, что им необходимо правильно настроить свои серверы для оптимальной производительности. Если они знают, что делают, у них все будет правильно с самого начала.

Answer 2

Сами инстансы делают что-то необычное, например, запросы к БД?И все они в верхней части страницы или включены по мере необходимости?

Эти статистические данные выглядят неплохо, поэтому, если доступ с правами администратора является редким, вы можете быть в порядке.Но вы должны изучить это с точки зрения дизайна: могут ли вещи быть организованы таким образом, чтобы вы не могли поддерживать так много включений?Помимо каких-либо проблем с производительностью, здесь есть риск создания трудно отслеживаемых ошибок зависимостей.

(Это может быть, как сказал MainMa, в отношении фреймворка, в этом случае вы можете не иметь никакого контроля надвыше. Я упоминаю об этом только в том случае, если вы это делаете.)

Несколько вещей, если вы еще не знали:

• Если это просто текст или статический HTML, вы можете получитьсодержимое с помощью file_get_contents (), readfile () и т. д. Это несколько быстрее, потому что загруженный файл не нуждается в разборе.Но очевидно, что если он содержит код PHP, это не поможет.
• Вы можете использовать include_once (), чтобы предотвратить включение одного и того же файла дважды (если, например, он включен двумя файлами, которые сами включены вфайл верхнего уровня).

Answer 3

Да , так много файлов может быть проблемой.

Нет , это, вероятно, не проблема в вашем случае , посколькуэто всего лишь серверная часть, к которой, вероятно, обращаются несколько человек, и не так часто.

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

Даже если время доступа к файлу крошечно, это время, которое вы теряете при каждом запросе.Этот крошечный период времени, умноженный на 148, может стать проблемой (и огромной проблемой масштабируемости).

Когда я работал над проектом фреймворка PHP, я использовал хитрость, чтобы уменьшить количество файлов.Несколько файлов были объединены в один уменьшенный файл, и этот единственный файл был кэширован.Затем, если возникла необходимость обновить фреймворк или веб-сайт, кэшированный файл был автоматически удален, а затем восстановлен.

Даже если я лично не рекомендую вам минимизировать исходный код (поскольку это трудно сделать,сложный для тестирования и создающий кучу проблем, таких как бессмысленное количество строк в ошибках), вы, вероятно, можете сделать то же самое, объединив все свои файлы в один файл.

Будьте осторожны: если страницаA использует половину этих файлов, а страница B - еще одну, объединяя все, что, вероятно, снизит производительность , поскольку движку PHP придется анализировать больше кода.

Answer 4

Честно говоря, не беспокойтесь об этом - 148 - ничто, даже если 0 кэширование произошло на стороне php, вы будете использовать fs-кеширование почти каждый раз - и, по большому счету, практически каждый open source что-либо естьгораздо больше файлов без проблем (drupal, wordpress, joomla, elgg, что угодно).

На самом деле, здесь нет проблем - даже если вам удавалось сбрасывать миллисекунды здесь или там, это так далеко в списке приоритетов.и места, где вы можете получить прирост скорости, вряд ли стоит обдумывать более секунды.

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

Answer 5

Дисковый ввод-вывод не будет вашей проблемой. Система будет кешировать часто используемые файлы в ОЗУ, или если они не так часто доступны, это не имеет значения.

Время загрузки может быть проблемой, поскольку каждый файл должен запрашиваться и интерпретироваться сервером отдельно.

Я не знаю, как веб-сервер справится со многими запросами; это может не заботиться. Если клиент не выполняет конвейерные запросы, вы заплатите за множество TCP-соединений, которые созданы и разорваны, что также требует значительных задержек.