Статические страницы, SSI и PHP — насколько быстрее?

Введение

В этом маленьком исследовании проверяется, насколько различается скорость обработки трёх видов HTML-страниц — статических, с использованием SSI и с использованием PHP — Web-сервером Apache.

Довольно очевидно, что статические страницы обрабатываются быстрее всего, использование SSI замедляет обработку страницы и использование PHP замедляет ещё больше, чем использование SSI. PHP почти всегда будет медленнее SSI поскольку объем синтаксического анализа в PHP несколько больше. Поэтому весь вопрос состоит только в количественном отличии трех технологий, качественно суть вещей более-менее понятна и без измерений.

Маленькое отступление: естественно, PHP позволяет сделать намного больше разных вещей, чем SSI. Поэтому если хочется сделать динамическую страницу, которая на SSI не реализуется или реализуется очень хитрым кодом, а на PHP кодируется проще, то лучше предпочесть PHP. Поэтому я буду рассматривать только достаточно простые случаи использования SSI и PHP: автоматическое включение общих меню, генерирование даты последнего изменения страницы, автоматическое генерирование ссылок и т.д. Другими словами, SSI и PHP будут использоваться в роли препроцессоров, облегчая ручное включение общих или автоматических элементов в HTML-файлы. Естественно, всё это можно делать и вручную.

Какие именно случаи тестируются

Тестируются следующие страницы:

Совершенно очевидно, что такие варианты использования 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 и самодисциплину?