Статичні сторінки, SSI та PHP - наскільки швидше
У цьому невеликому дослідженні перевіряється, наскільки різниться швидкість обробки трьох видів 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 та самодисципліну?