Разве плохо включать в PHP много файлов, как это делается для файловых сессий?

Question

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

Answer 1

Вы должны использовать spl_autoload_register () и ООП. Таким образом, независимо от того, насколько мал ваш проект в настоящее время или насколько он будет развиваться со временем (и было бы глупо исключать эту возможность), PHP будет включать только то, что ему нужно, не больше, не меньше.

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

Сказав это, это означает, что неправильно включать неиспользуемые файлы.

Включение файлов, независимо от того, каким способом (spl_autoload_register () или иным образом), должно выполняться с абсолютными путями из-за директивы php.ini include_path, через которую PHP будет искать ваши файлы при использовании относительных путей. *

И небольшая дополнительная заметка о том, почему «include» foo.php »работает как« include »./foo.php» («нормальный» способ включения файлов): это потому, что каталог «.» по умолчанию является частью include_path.

Answer 2

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

Мой опыт показывает, что да, если вы всегда загружаете все свои библиотеки, то это потребляет драгоценную память (из которой вам выделяется только фиксированное количество мегабайт на процесс). У меня были файлы исходного кода весом 300-400 КБ (с комментариями), которые съедали 2-3 МБ на экземпляр скрипта. Принимая во внимание, что сценарий получает только 16-32 МБ со многими общими хостами, это lot . Кроме того, обработка таких огромных файлов часто занимает до полсекунды на запрос, что слишком много.

Итак, разделение, безусловно, необходимо, и это легко сделать с помощью автозагрузки и консортов. Посмотрите мой ответ на этот вопрос , чтобы получить несколько советов о том, как разумно разделить ваш код. Также есть ссылка на вопрос о том, как организовать большой PHP-проект , который дал отличные результаты. Я сам нахожусь в процессе выяснения идеальной структуры, но еще не закончил. :)

Answer 3

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

Если бы вы на самом деле использовали microtime функцию PHP для измерения того, сколько времени это заняло, это было бы за миллиардные доли секунды.

Answer 4

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

Answer 5

Как писал Chacha102, это не так уж и плохо.

Но это также зависит от ваших реальных файлов скриптов.

На практике вы должны профилировать свой код, Xdebug отлично подходит для этого.

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

Answer 6

Другой вариант - «ленивые» включаемые файлы, например require_once их перед их использованием (пример создания экземпляра класса), чтобы не происходила (вроде) целая загрузка неиспользуемых включений.

Я использовал функцию Zend по этому поводу (регистрация автозагрузки), но я не знаю, является ли она общей для php или нет, но существует для других фреймворков ...

Answer 7

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