Вопросы производительности PHP?

Question

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

Являются ли простые include() заявления проблемой скорости или масштабирования, в отличие от статических HTML? Какие вещи могут вызвать срыв сайта?

Answer 1

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

Использование кеширования тоже не поможет - кеширование кода будет выполняться медленнее, чем просто include (). Кэширование может принести вам пользу только в том случае, если вы выполняете вычислительные вычисления (очень редко, на веб-страницах) или извлекаете данные из базы данных.

Answer 2

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

Включает в себя факт жизни. Не беспокойтесь о количестве, заботьтесь о том, чтобы ваш код был хорошо организован (структура папок PEAR - прекрасная вещь, если вы не знаете, о чем я говорю, посмотрите на структуру файлов классов Zend Framework).

Сосредоточьтесь на том, чтобы приложение было написано с достаточным количеством абстракций. Сгруппируйте все ваши вызовы БД в класс (или классы), чтобы минимизировать дублирование кода (принципы KISS и все), а когда придет время для рефакторинга и оптимизации ваших запросов, они будут расположены в центре. Также начните тестирование, чтобы предотвратить регрессию.

Как только приложение будет запущено и запущено, не спрашивайте нас, что быстрее или лучше, поскольку от каждого приложения зависит ваше узкое место. Может получиться так, что даже если у вас много включений, ваши циклы поглощают ваше время или что-то еще. Используйте XDebug и для профилирования вашего кода после его запуска и запуска. Ищите сегменты кода, которые потребляют непропорционально много времени, а затем рефакторинг. Если вы слишком сосредоточитесь сейчас на снижении производительности между include и include_once, вы в конечном итоге будете гоняться за призраком, когда эти синхронные запросы curl едят ваш завтрак.

Хотя, в то же время, лучшие предложения - это просмотреть руководство по php.net и убедиться, что есть встроенная функция, выполняющая то, что вы пытаетесь сделать, используйте ее! PHP-расширения на основе C всегда будут быстрее, чем любой PHP-код, который вы могли бы написать, и вы будете удивлены, насколько многое из того, что вы пытаетесь сделать, уже сделано.

Но опять же, я не могу не подчеркнуть этого достаточно, преждевременная оптимизация - ПЛОХАЯ !!! Просто поднимите свое приложение с нуля с хорошими уровнями абстракции, профилируйте его, а затем исправьте то, что фактически съедает ваше время, а не исправление того, что, по вашему мнению, может съесть ваше время.

Answer 3

Строго говоря, прямой HTML всегда будет работать быстрее, чем подход на стороне сервера, так как сервер не должен интерпретировать код.

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

Одна вещь, которую я заметил, это то, что самые медленные сайты на PHP - это те, которые содержат больше, чем необходимо для отображения конкретной страницы. OSCommerce (oscommerce.com) - одна из самых популярных тележек для покупок на PHP. Однако у него есть плохая привычка включать все их основные функции (на всякий случай, если это необходимо) на каждую страницу. Таким образом, даже если вам не нужно отображать «информационное окно», функция загружается. С другой стороны, существует множество PHP-фреймворков (таких как CakePHP, Symfony и CodeIgniter), которые используют подход «загружай, как тебе нужно».

Я бы посоветовал следующее:

1. Не включайте больше функций, чем нужно для конкретной страницы
2. Хранить базовые функции отдельно (по возможности используйте подход MVC)
3. Используйте require_once вместо include, если вы думаете, что у вас есть вложенные включения (например, страница A включает файл B, который включает файл C). Это позволит избежать включения одного и того же файла более одного раза. Это также остановит процесс, если файл не найден; тем самым помогая вашему процессу устранения неполадок;)
4. Кэшируйте статические страницы в HTML, если это возможно, чтобы избежать повторного анализа, когда ничего не меняется

Answer 4

Нах, в порядке, ничего страшного.

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

Большинство веб-приложений ограничены скоростью своей базы данных (или какой бы то ни было их внешней памятью, но в 9/10 раз это будет база данных), код приложения редко вызывает беспокойство, и он не звучит как будто вы делаете все, о чем вам нужно беспокоиться.

Answer 5

Прежде чем принимать какие-либо долгосрочные решения о том, как структурировать код для вашего сайта, я бы порекомендовал вам немного почитать шаблон проектирования Model-View-Controller . В то время как есть другие, этот, кажется, получает большой успех в кругах веб-разработки и, безусловно, будет некоторое время. Возможно, вы захотите взглянуть на некоторые другие шаблоны проектирования, предложенные Мартином Фаулером в его шаблонах архитектуры корпоративных приложений , прежде чем принимать окончательное решение о том, какой тип дизайна наилучшим образом соответствует вашим потребностям.

В зависимости от размера и масштаба вашего проекта, вы можете использовать готовые рамки для PHP, такие как Zend Framework или PHP On Trax, или вы можете решить создать собственное решение.

В частности, в отношении визуализации содержимого HTML, я настоятельно рекомендую вам использовать какую-либо форму шаблонов, чтобы отделить бизнес-логику от логики отображения. Я обнаружил, что это одно простое правило в моей разработке сэкономило мне часы работы, когда нужно было изменить одно или другое. Я использовал http://www.smarty.net/">Smarty и знаю, что большинство фреймворков либо имеют собственную систему шаблонов, либо предоставляют подключаемую архитектуру, которая позволяет вам использовать свой предпочтительный метод. Когда вы смотрите на возможные решения, я бы порекомендовал вам найти решение, способное создавать кэшированные версии.

Наконец, если вы беспокоитесь о скорости на бэкэнде, я настоятельно рекомендую вам поискать способы минимизировать ваши звонки в вашем бэк-хранилище данных (будь то база данных или просто системные файлы). Старайтесь избегать загрузки и рендеринга слишком большого количества контента (скажем, большого отчета, хранящегося в таблице, содержащей сотни записей) одновременно. По возможности ищите способы заставить пользовательский интерфейс загружать меньшие биты данных за раз. И если вас особенно беспокоит фактическое время загрузки вашего html-контента и его CSS, Javascript или других зависимостей, я бы порекомендовал вам просмотреть эти предложения от ребят из Yahoo!.

Answer 6

Самое большое, что вы можете сделать для ускорения работы вашего приложения, - это использовать кэш Opcode, например APC . В Wikipedia .

есть отличный список и описание.

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

Answer 7

Чтобы добавить то, что упоминал JayTee - загрузка функциональности, когда вам это нужно. Если вы не используете какую-либо платформу, которая делает это автоматически, вы можете захотеть изучить функциональность __autoload (), которая была представлена ​​в PHP5 - в основном, ваша собственная логика может быть вызвана, когда вы создаете конкретный класс, если это еще не сделано загружен. Это дает вам возможность включить () файл, который определяет этот класс по требованию.