1. замість передмови
2. експериментальна модель
3. експериментальне обладнання
4. Дані «сирого» сервера
5. оптимізація PHP
6. оптимізація MySQL
7. тести LoadImpact
8. замість висновку

Сама по собі інструкція про те, де що підкрутити на сервері, щоб Drupal став працювати швидше, зустрічаються на просторах інтернету в різному ступені деталізації. Однак все зустрічалися мені статті володіли невеликою вадою: я не зустрічав будь-яких реальних вимірів, що супроводжували налаштування. Як чисельно змінюється швидкість генерації сторінки? Як змінюється використання пам'яті? Що відбувається при збільшенні кількості паралельних запитів? Давайте проведемо експеримент. Деякі рекомендації, викладені в статті, носять загальний характер і можуть бути корисні для інших CMS.

замість передмови

В основу даної статті лягла добірка матеріалів Server tuning considerations , Розміщена на офіційному сайті Drupal. З неї відібрано те, що носить найбільш універсальний характер і може бути застосовано до довільного сервера, на якому планується використання Drupal (зокрема, секції, що стосуються налаштування PHP і MySQL). Ця стаття не охоплює питання тонкої настройки самої CMS.

експериментальна модель

Для перевірки навантаження був створений якийсь еталонний важкий сайт. Для цього був використаний Drupal 7 і кілька популярних модулів, в тому числі Views і Pathauto. В один з типів матеріалу було додано числове поле, яке могло приймати значення від 1 до 10. За допомогою функції генерації контенту модуля Devel було створено близько 10 тис. Сторінок матеріалу даного типу і від 0 до 15 коментарів до кожного посту.

Далі був створений і розміщений на головній сторінці блок Views, що вибирає 100 випадкових сторінок, де поле приймало значення 5 (тобто, якщо вірити теорії ймовірності, 100 з 1000 сторінок) разом з коментарями до них. Критерій фільтрації Global: Random був використаний, щоб сторінка гарантовано генерировалась по-новій при кожному завантаженні. На особистому тестовому сервері час генерації такої сторінки становило приблизно 10 секунд. Також при підготовці було піднято тестовий інтернет-магазин на базі Commerce Kickstarter і згенеровано близько 5 тис. Товарів. Однак з'ясувалося, що Global: Random абсолютно не дружить з Search API, а без рандомізації сторінка з 96 продуктами вантажилася відчутно швидше, ніж попередня тестова сторінка. Тому виміри по швидкодії інтернет-магазину не проводилися. Тестові сайти були перенесені на ...

експериментальне обладнання

Для експериментів я запозичив на кілька днів свіжовстановленому VPS Intel Xeon E3-1230 3.2GHz / 2-3 GB RAM / 30 GB SSD і Intel Xeon E3-1230 / 8GB DDR3 / 4x1TB SATA2 / 100Mbps Unmetered в Нідерландах (далі по тексту - VPS і Е3-1230 відповідно). На серверах були стандартно налаштовані LAMP + Nginx. Основна частина вимірів проводилася утилітою ab із загальним числом запитів 1000 і числом паралельних запитів від 10 до 50. Після закінчення також було запущено кілька тестів Loadimpact.

Дані «сирого» сервера

Перший вимір був проведений до початку будь-якої оптимізації. Власне, в цих вимірах я зупинився на 40 паралельних запитах. Отримані результати виглядають приблизно так:

На цьому і наступних аналогічних графіках по осі X буде частка запитів, які були обслужені за час, що не перевищує відповідного значення по осі Y.

Крім того, інтересу заради я запустив безкоштовний тест Loadimpact, однак будь-якої відчутної навантаження він не створив.

оптимізація PHP

Перше, що потрібно зробити на сервері під Drupal, - виставити в php.ini значення memory_limit хоча б 256M. Як правило, цього цілком достатньо для більшості сайтів. А ось 128M часом виявляється замало. Втім, це не можна назвати оптимізацією, це скоріше життєва необхідність.

Для прискорення роботи сайтів на рівні PHP розробники рекомендують використовувати різні кешируєтся оптимізатори. В інших джерелах найчастіше згадується APC, тому до нього я і звернувся. Про те, як його поставити, можна почитати в інструкції . Зараз же нас цікавлять ключові параметри налаштування. Власне, основний параметр - розмір сегмента пам'яті кеша, apc.shm_size. Чим більше огрядна сторінка, чим більше різних файлів підключається при виконанні, тим більше повинно бути значення. Наприклад, тестового сайту вистачило 64M. А тестовий магазин при цьому значенні видав помилку:

[Mon Jan 13 21:41:46 2014] [error] [client 176.36.31.190] PHP Warning: Unknown: Unable to allocate memory for pool. in Unknown on line 0, referer: http://s2shop.1b1.info/products?page=2

Підняття значення до 256M вмить прибрало цю проблему. За даними модуля Devel, при разових переглядах сайтів включення кешування вплинуло на такі параметри:

• в півтора-два рази скоротився час генерації сторінки;
• скоротилося пікове споживання пам'яті з приблизно 50-55 MB до 30-32 MB для тестового сайту і з приблизно 65-70 MB до 30-32 MB для тестового магазину.

Про те, як вплинуло включення APC на результати бомбленія за допомогою ab, ми розповімо пізніше. За загальнодоступною публічної інформації, чудові результати дає використання php-fpm замість Apache + mod_php. Однак я поки не пробував порівнювати ці дві конфігурації.

оптимізація MySQL

Один з найпростіших способів оптимізувати MySQL - замінити my.cnf на my-huge.cnf. Цей файл розрахований на системи з достатнім (2 Гб і вище) кількістю оперативки і масштабним використанням MySQL. Крім усього іншого, від стандартного конфіга він відрізняється істотно великим розміром буфера (key_buffer_size) і включенням кешування запитів (query_cache_size).

Загальна зміна швидкості віддачі при послідовному застосуванні виглядає приблизно так.

Е3-1230, 10 паралельних запитів

VPS, 10 паралельних запитів

Е3-1230, 30 паралельних запитів

VPS, 30 паралельних запитів

Як можна помітити, на VPS розрив між неоптимізованими MySQL і оптимізованим помітніше, ніж на E3-1230. Смію припустити, що це пов'язано з використанням SSD дисків на VPS. Зараз все популярнішими стають конфігурації серверів, в яких бази даних виносяться на SSD. З огляду на, наскільки істотно за останній час вони подешевшали, таке рішення не сильно б'є по кишені і в багатьох випадках дозволяє помітно прискорити роботу сайтів. Плюсом на користь SSD, на мою думку, є і два наступних графіка.

E3-1230, 50 паралельних запитів

VPS, 50 паралельних запитів

Як бачимо, на сервері з SATA дисками буферизация з кешуванням дуже швидко починають захлинатися. При цьому на VPS з SSD дисками загальна тенденція зберігається. На VPS я спробував ще збільшити значення key_buffer_size і query_cache_size, завдяки чому отримав незначний, але стабільний приріст продуктивності (крива MySQL 2). Втім, на цьому етапі на обох конфігураціях вже починає захлинатися процесор.

тести LoadImpact

Проведені за допомогою утиліти ab тести показують не реальну завантаження сторінок сайту, а скоріше якісна зміна продуктивності. Для якихось більш наближених до життя даних я провів пару тестів за допомогою Loadimpact .

1. На головну сторінку тестового сайту були нацьковано до 100 SBU, приблизно рівномірно розподілених по 5 різних локаціях (2 в США, 2 в Європі, 1 в Австралії). Сумарний графік не дозволяє побачити, напружила чи сервер це навантаження хоч скільки-небудь.

   

   Але зростання навантаження стає помітнішою, якщо дивитися графіки суто за європейськими точкам, з якими зв'язність краще.

   

   При цьому загальний потік даних був близький до 90 Мбіт / с. Хотілося наздогнати канал до полички, але не залишилося кредитів.

   

   Навантаження на процесор стає помітною, проте Load average не йде ні в яке порівняння з тестами ab.

   

2. На закінчення я склоніровал звичайний невеликий інформаційний СДЛ і нацькував на нього Loadimpact з 8 різних точок. Всі точки тестування зверталися до різних сторінках сайту. За 10 хвилин кількість SBU також дійшло до 100.

   

   Віддача була вельми рівномірної, без будь-яких явних вповільнень.

   

   При цьому сервер цього тесту практично не помітив.

   

замість висновку

Я розглянув вплив на швидкість роботи сайту всього двох істотних параметрів, тому буду вдячний всім, хто зможе дати додаткові корисні поради з порушеної теми. Крім того, десь днів 5 після публікації тестові середовища ще залишатимуться живі, і якщо у Вас є ще якісь рекомендації по оптимізації або пропозиції по тестуванню, я постараюся за цей період втілити їх в життя і додати до статті. Закликаю всіх обмінюватися власним досвідом оптимізації і своїми хитрощами. І спасибі, що терпляче дочитали.