В этом маленьком исследовании проверяется, насколько различается скорость обработки трёх видов HTML-страниц — статических, с использованием SSI и с использованием PHP — Web-сервером Apache. Довольно очевидно, что статические страницы обрабатываются быстрее всего, использование SSI замедляет обработку страницы и использование PHP замедляет ещё больше, чем использование SSI.
PHP почти всегда будет медленнее SSI поскольку объем синтаксического анализа в PHP несколько больше. Поэтому весь вопрос состоит только в количественном отличии трех технологий, качественно суть вещей более-менее понятна и без измерений.
Маленькое отступление: естественно, PHP позволяет сделать намного больше разных вещей, чем SSI. Поэтому если хочется сделать динамическую страницу, которая на SSI не реализуется или реализуется очень хитрым кодом, а на PHP кодируется проще, то лучше предпочесть PHP. Поэтому я буду рассматривать только достаточно простые случаи использования SSI и PHP: автоматическое включение общих меню, генерирование даты последнего изменения страницы, автоматическое генерирование ссылок и т.д. Другими словами, SSI и PHP будут использоваться в роли препроцессоров, облегчая ручное включение общих или автоматических элементов в HTML-файлы. Естественно, всё это можно делать и вручную.
Тестируются следующие страницы:
- полностью статическая, полученная по результатам препроцессирования PHP-версии тестовой страницы;
- страница, использующая SSI для включения статических заголовка-меню и подвала-меню (использовалась инструкция «include virtual») и генерирования времени последнего изменения файла,
- страница, использующая PHP для генерирования динамических, зависящих от текущей страницы, заголовка-меню и подвала-меню и генерирования времени последнего изменения файла; динамичность заголовка-меню состоит в убирании из меню ссылки на саму страницу как учит нас Артемий Лебедев.
Совершенно очевидно, что такие варианты использования SSI и PHP существенно различны и PHP делает больше операций, чем SSI. Но меня интересовало количественное сравнение именно этих ситуаций: хотелось понять, насколько медленнее будет использование PHP для получения «динамических» навигационных меню. Но для полноты картины я протестирую и совсем «простой» случай генерирования времени последнего изменения файла и включения одного статического внешнего файла средствами SSI и PHP, который будет сравниваться со статической страницей.
Условия тестирования
Программная часть: использовалась связка Apache 2.2 и PHP 5.1.
Производительность мерялась утилитой Webbench.
В качестве среды передачи использовалась локальная сеть Ethernet со скоростью 100 Mbit/sec. В момент тестирования сеть чувствовала себя хорошо и готова была выдержать ещё около пятидесяти таких тестов, запущенных параллельно.
Было сделано по 63 чередующихся прогона загрузки страницы каждого типа. Один прогон длился 10 минут и Webbench симулировал 30 клиентов. Среднее значение вычислялось по обычной формуле: сумма всех результатов, деленная на количество результатов.
Мы видим, что для «сложного» случая PHP отстает от статической страницы в два раза. SSI опережает PHP на величину порядка 25%, но, естественно, отстает от статической страницы на 25%.
«Простой» случай сокращает отставание PHP от статической страницы до 27% и соответствующее отставание SSI — до 12%. Разница в результатах SSI для двух случаев вызвана тем, что мы используем инструкцию «include virtual», которая вызывает обращение к включаемому документу по протоколу HTTP. В «простом» случае обращение одно, а в «сложном» — два: заголовок-меню и подвал-меню. При использовании инструкции «include file» разрыв между SSI и статической страницей сокращается до 1.5%, как видно из третьей серии результатов.
Выводы
PHP проигрывает SSI на поле деятельности SSI — в простых случаях включения файлов и генерирования даты последней модификации. Проигрыш составляет величину порядка 25%.
PHP ещё больше проигрывает SSI в случае создания «динамического» содержания страниц: около 34%, но в таком сценарии использования PHP выигрывает в функциональности — для этого он и создавался ;-)
Если вы выбираете между директивами SSI «include file» и «include virtual», то первая из директив на маленьких размерах включаемых документов будет очень сильно обходить вторую. Выбирать приходится потому, что «include virtual» иногда удобнее: мы не привязаны к физическому пути документа, а используем URL. Вывод, конечно, тривиальный.
Последний вывод: PHP лучше, если вы используете его как offline-средство, то есть генерируете с его помощью статические страницы, которые потом будут отдаваться Web-сервером. При этом вы комбинируете мощь PHP со скоростью статических страниц. Одно «но»: при этом вы получаете дополнительную работу по преобразованию PHP-страниц в статические и ошибки, связанные с тем, что PHP-версия была поправлена, а статический эквивалент не поменяли. Но кто отменял автоматические средства сборки, cron и самодисциплину?
