Сколько «включенных» слишком много как часть общей последовательности запуска скрипта?Или такого нет?

Question

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

То, что я хочу знать, это то, возможно ли иметь слишком много из них и в результате сделать вещи медленнее. Я знаю, что использование include() имеет определенную нагрузку, потому что это другой файл, который нужно искать в файловой системе, анализировать и выполнять. Если есть такая вещь, как слишком много include с, я хочу знать, нахожусь ли я где-нибудь рядом с этой точкой. Нотабене Некоторые из моих страниц include() все еще содержат больше скриптов, которые им конкретно нужны (например, скрипт, который определяет функцию, используемую только несколькими страницами), и я не считаю эти случайные дополнительные include s, которые используются в любом случае достаточно экономно Я беспокоюсь только о 3 include s, которые появляются на большинстве страниц и настраивают все.

Что такое 3 include с?

Два из них находятся вне webroot. common.php определяет набор функций, классов и других вещей, которые не различаются между сайтами разработки и производства. config.php определяет различные константы и пути, которые различаются на сайтах разработки и производства (среди прочего, к какой базе данных подключаться). Конечно, желательно, чтобы этот файл находился вне webroot. config.php include() с common.php внизу.

Другой находится внутри webroot и содержит одну строку:

include [path to appropriate directory]/config.php

Каталог отличается между разработкой и производством сайтов.

(Не стесняйтесь спрашивать об обосновании настройки includes таким образом, но я чувствую, что это обеспечивает хорошую, надежную систему для подготовки к выполнению каждой страницы, и мой вопрос о том, плохо ли иметь столько include в качестве базовой линии на каждой странице.)

Answer 1

Используйте APC и ваши заботы исчезнут. код операции ваших файлов будет кэширован в ОЗУ , и все будет идти супер быстро . :) Facebook делает это , поэтому он определенно поможет вам масштабировать .

Поскольку вы можете не заметить никакой разницы между 1 включением или 50 с точки зрения скорости, но для приложения с высоким параллелизмом ввод / вывод может быть огромным узким местом . Таким образом, ключ не скорость, а масштабирование.

Answer 2

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

Например, друг провел эксперимент на своем веб-сайте, на котором около 15 тыс. Пользователей в день и среднее время загрузки страницы составляет 0,03 с. Он удалил большинство включений, которые он использовал в качестве шаблонов - среднее время загрузки сократилось до 0,01 сек. Затем он поставил ускоритель - 0,002 секунды на страницу. Я надеюсь, что эти цифры убедят вас в том, что на загруженных сайтах нужно хранить как можно меньше записей, если вы не используете какой-либо ускоритель.

Это из-за высокого ввода-вывода, необходимого для сканирования каталогов, поиска файлов, их открытия, чтения и так далее.

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

Answer 3

Или, если вы случайно используете Windows в качестве ОС, вы можете использовать WinCache .http://php.net/manual/en/book.wincache.php

Answer 4

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