Я строил сайт PHP, но пока только PHP, который я использую, составляет полдюжины или около того на определенных страницах. (В конечном итоге, я, вероятно, буду использовать некоторые запросы к базе данных.)Вопросы производительности PHP?
Простые include() заявления о скорости или масштабировании, а не статические HTML? Какие вещи, как правило, заставляют сайт бояться?
Строго говоря, прямой HTML всегда будет работать быстрее, чем серверный подход, поскольку серверу не нужно выполнять какую-либо интерпретацию кода.
Чтобы ответить на вопрос большего, - это ряд вещей, которые могут привести к тому, что ваш сайт начнет болеть; просто нет определенного порога, когда ваш код вызывает проблему против PHP. (имейте в виду, что многие сайты Yahoo ориентированы на PHP, поэтому не думайте, что PHP не может масштабироваться).
Одна вещь, которую я заметил, это то, что сайты с наивысшей скоростью, основанные на PHP, - это те, которые содержат больше, чем необходимо для отображения определенной страницы. OSCommerce (oscommerce.com) является одной из самых популярных корзин для покупок с помощью PHP. Однако у него есть плохая привычка включать все свои основные функции (на всякий случай, если это необходимо) на каждую страницу. Поэтому, даже если вам не нужно отображать «информационное окно», функция загружается. С другой стороны, существует много фреймворков PHP (таких как CakePHP, Symfony и CodeIgniter), которые используют подход «загрузить его по мере необходимости».
Я бы посоветовал следующее:
Конечно, include() медленнее статических страниц. Однако с современными системами вы вряд ли увидите это как узкое место в течение длительного времени - если когда-либо. Преимущества использования включают в себя, чтобы поддерживать общие части вашего сайта в актуальном состоянии, перевешивают крошечный хит производительности, на мой взгляд (с другой навигацией на одной странице, потому что вы забыли обновить ее, что приводит к плохому пользовательскому опыту и, как следствие, к плохим чувствам сайт/компания/все).
Использование кэширования действительно не поможет - код кеширования будет медленнее, чем просто include(). Единственное временное кэширование принесет пользу вам, если вы делаете вычисления с использованием вычислительных ресурсов (очень редко, на веб-страницах) или захватываете данные из базы данных.
Nah включает в себя все в порядке, не о чем беспокоиться.
Возможно, вы захотите немного подумать о настройке ваших кеширующих заголовков, но если вы не получаете значительных ударов, это не должно быть проблемой. Предполагая, что это все статические данные, вы даже можете рассмотреть возможность преобразования всего сайта в статический HTML (самый простой способ: написать сценарий, который захватывает каждую страницу через веб-сервер и выгружает ее в соответствующей структуре dir)
Большинство веб-приложений ограниченные скоростью их базы данных (или независимо от их внешнего хранилища, но в 9/10 раз это будет база данных), код приложения редко вызывает беспокойство, и это не похоже на то, что вы делаете что-либо, что вы еще нужно беспокоиться.
Чтобы добавить о том, что упомянутый Джейти - функциональность загрузки, когда вам это нужно. Если вы не используете какие-либо фреймворки, которые делают это автоматически, вам может понадобиться изучить функциональность __autoload(), которая была введена в PHP5 - в основном ваша собственная логика может быть вызвана при создании экземпляра определенного класса, если он еще не создан загружен. Это дает вам возможность включить() файл, определяющий этот класс по требованию.
Прежде чем принимать какие-либо долговременные решения о том, как структурировать код для вашего сайта, я бы рекомендовал вам прочитать некоторые сведения о шаблоне проектирования Model-View-Controller. В то время как есть другие, этот, похоже, набирает много места в кругах веб-разработки и, конечно же, будет на некоторое время. Возможно, вам стоит взглянуть на некоторые другие шаблоны дизайна, предложенные Мартином Фаулером в его Patterns of Enterprise Application Architecture, прежде чем принимать окончательные решения о том, какой дизайн лучше всего подходит вашим потребностям.
В зависимости от размера и объема вашего проекта, вы можете захотеть пойти с готовым фреймворком для PHP, например Zend Framework или PHP On Trax, или вы можете решить создать собственное решение.
В частности, в отношении рендеринга содержимого HTML я настоятельно рекомендую вам использовать какую-либо форму шаблонов, чтобы ваша бизнес-логика отличалась от вашей логики отображения. Я обнаружил, что это одно простое правило в моей разработке сэкономило мне часы работы, когда нужно было изменить один или другой. Я использовал http://www.smarty.net/">Smarty, и я знаю, что большинство фреймворков там либо имеют собственную систему шаблонов, либо предоставляют подключаемую архитектуру, которая позволяет использовать ваши собственные предпочтительные Как вы смотрите на возможные решения, я бы рекомендовал вам искать тот, который способен создавать кешированные версии.
Наконец, если вас беспокоит скорость на задней панели, я бы настоятельно рекомендовал вам посмотрите, как свести к минимуму ваши вызовы в хранилище данных (будь то база данных или только системные файлы). Старайтесь не загружать и не отображать слишком много контента (скажем, большого отчета, хранящегося в таблице, содержащей сотни записей). Если возможно, найдите способы заставить пользовательский интерфейс загружать меньшие биты данных за один раз. И если вас особо беспокоит фактическое время загрузки вашего html контента и его CSS, Javascript или других зависимостей. Я бы порекомендовал вам ознакомиться с these suggestions от ребята в Yahoo !.
Исправить ссылку в этом ??? – Mez 2008-09-22 07:41:25
Самое важное, что вы можете сделать, чтобы ускорить ваше приложение, - использовать кеш-память Opcode, например APC. Отличный список и описание доступны по адресу Wikipedia.
Что касается простых включений, будьте осторожны, чтобы не включать слишком много файлов в каждый запрос, поскольку дисковый ввод-вывод может привести к тому, что приложение не будет хорошо масштабироваться. Несколько десятков включений должны быть прекрасными, но обычно рекомендуется упаковывать ваши наиболее часто включенные файлы в один скрипт, поэтому у вас есть только один. Стоимость памяти с несколькими классами здесь и там, которую вы не загружаете, будет лучше, чем стоимость дискового ввода-вывода для включения в нее сотен меньших файлов.
На самом деле использование кеша операций с кодовым кодом значительно ускоряет включение и уменьшение дискового ввода-вывода, поскольку код уже находится в памяти, и нет необходимости в доступе к HD. – AdamTheHutt 2008-09-22 11:13:52
Похоже, вы участвуете в немного преждевременной оптимизации. Если приложение не построено, в то время как проблемы с производительностью хорошо знают, ваша основная задача должна заключаться в том, чтобы приложение было написано.
Включает в себя факт жизни.Не беспокойтесь о количестве, беспокоитесь о том, что ваш код хорошо организован (структура папок PEAR - это замечательная вещь, если вы не знаете, что я говорю, посмотрите на структуру файлов классов Zend Framework).
Сфокусируйтесь на получении заявки, написанной с разумным объемом абстракции. Группируйте все вызовы БД в класс (или классы), чтобы свести к минимуму дублирование кода (принципы KISS и все), а когда пришло время реорганизовать и оптимизировать ваши запросы, они расположены централизованно. Также приступайте к тестированию отдельных модулей для предотвращения регрессии.
Как только приложение запущено, не спрашивайте нас, что быстрее или лучше, поскольку зависит от каждого приложения, каково будет ваше узкое место. Может получиться, что, хотя у вас много включений, ваши петли ели ваше время или что-то еще. Используйте XDebug и profile your code после его запуска. Ищите сегменты кода, которые потребляют непропорциональное количество времени, а затем рефакторинг. Если вы сейчас слишком много внимания уделяете удару производительности между include и include_once, вы в конечном итоге преследуете призрак, когда эти запросы на завихрение, выполняющиеся в синхронизации, завтракают.
Хотя, в то же время, лучшие предложения - это просмотреть руководство по php.net и убедиться, что есть встроенная функция, выполняющая то, что вы пытаетесь сделать, используйте ее! Расширения на основе C на PHP всегда будут быстрее, чем любой PHP-код, который вы могли бы написать, и вы будете удивлены, сколько из того, что вы пытаетесь сделать, уже сделано.
Но опять же, я не могу этого достаточно подчеркнуть, преждевременная оптимизация - ПЛОХО !!! Просто приложите свое приложение к земле с хорошим уровнем абстракции, профилируйте его, затем исправьте то, что на самом деле съедает ваше время, а не фиксируйте то, что, по вашему мнению, может съесть ваше время.
Чувство, что «require_once» медленнее, чем «include», поскольку PHP должен отслеживать включенные файлы и перекрестно проверять каждый раз, когда вы вызываете «require_once». – mixdev 2010-07-13 21:42:00