Оптимізація продуктивності веб-сервера Apache

1. Завантажуйте тільки необхідні модулі
2. Виберете відповідний MPM
3. DNS lookup
4. AllowOverride
5. FollowSymLinks і SymLinksIfOwnerMatch
6. Content Negotiatio
7. MaxClients
8. MinSpareServers, MaxSpareServers, і StartServers
9. MaxRequestsPerChild
10. KeepAlive і KeepAliveTimeout
11. стиснення
12. Кешування на стороні клієнта

Apache - популярний веб-сервер в інтернет, він обслуговує безліч серверів і сайтів. Часто виникає необхідність збільшити продуктивність веб-сервера. напевно кращий спосіб це зробити - перейти до схеми frontend + backend, але це може зажадати досить серйозних змін в додатку (наприклад, у вас напевно відваляться всілякі індикатори прогресу аплоаду файлів :).

інший спосіб - просто збільшити продуктивність сервера - поставити більш швидкий процесор і більше пам'яті.

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

Завантажуйте тільки необхідні модулі

Apache - модульна програма, велика частина функцій якої реалізується в модулях. При цьому ці модулі можуть бути як вкомпільовані, так і зібрані у вигляді DSO - динамічних бібліотеках. Більшість сучасних дистрибутивів поставляє apache з набором DSO, так що не потрібні модулі можна, можливо легко відключити без перекомпіляції.

Запускайте apache тільки з необхідними модулями, щоб зменшити споживання пам'яті. Якщо ви вирішили скомпілювати apache самостійно, то або ретельно підходите до вибору списку модулів, які ви включите, або компілюйте їх як DSO використовуючи apxs в apache1 і apxs2 в apache2. Для того щоб відключити непотрібні DSO-модулі, досить закомментировать зайві рядки LoadModule в httpd.conf. Apache зі статично скомпільованими модулями буде споживати трохи менше пам'яті, проте вам доведеться кожного разу його перекомпіліровать для зміни списку модулів.

Виберете відповідний MPM

У apache кожен запит обробляється в своєму процесі або потоці. При компіляції apache дозволяє вибирати один з кількома MPM (Multi-processing module), які відповідають за прослуховування портів, прийом запитів і роздачу цих запитів дочірнім процесам або потокам, в яких ці запити будуть оброблені.

Вибір MPM залежить від декількох факторів, таких як наявність підтримки потоків в ОС, кількості вільної пам'яті, а також вимог стабільності і безпеки.

Якщо безпека дуже важлива, слід вибрати peruser MPM, пожертвувавши продуктивністю.

Якщо важлива саме продуктивність, то вибір обмежується двома mpm: prefork і worker.

Worker - потоковий MPM, тобто в ньому кожен запит обслуговується в окремому потоці одного з дочірніх процесів. Потоки - легші для ОС об'єкти, ніж процеси, вони більш ефективно використовують пам'ять і перемикання контексту для них відбуваються швидше. Однак, через те що кожен потік має доступ до всієї пам'яті процесу, worker mpm більш схильний до збоїв: збій одного потоку може спричинити падіння всього процесу, в якому знаходився цей потік (саме тому worker mpm запускає кілька дочірніх процесів з декількома потоками в кожному).

Perfork - mpm використовує кілька дочірніх процесів, кожен дочірній процес обробляє одне підключення. Через те що процес - більш важка структура, він використовує трохи більше ресурсів, зате він менш схильний до збоїв - обробка кожного окремого запиту не залежить від інших процесів.

На жаль, для зміни mpm потрібно перекомпіляція apache. Тут проявляють свої переваги source-based дистрибутиви: ви можете легко переконфігурувати apache і всіх залежних від нього пакети, які не перетворивши систему в смітник. Бінарні дистрибутиви виходять з цієї ситуації по-різному. Наприклад в RHEL в apache rpm знаходиться відразу дві версії apache - з worker і prefork mpm (prefork використовується за умовчанням). Однак worker mpm не підтримує php. Так що якщо ви хочете php і worker mpm вам доведеться компілювати його самостійно або шукати сторонні репозиторії.

DNS lookup

Директива HostnameLookups включає reverse DNS запити, так що в логи потраплятимуть dns-хости клієнтів замість ip-адрес. Зрозуміло, що це істотно сповільнює обробку запиту, тому що запит не обробляється поки не буде отримає відповідь від DNS-сервера. Тому стежте щоб ця директива завжди була вимкнена (HostnameLookups Off), а якщо вам все-таки потрібні dns-адреси, ви можете дізнатися їх пізніше, прогнавши лог в утиліті logresolve (яка поставляється з apache).

Крім того, стежте щоб в директивах Allow from і Deny From використовувалися ip-адреси а не доменні імена. Інакше apache робитиме два dns запиту (зворотний і прямий) щоб переконатися що клієнт-той за кого себе видає.

AllowOverride

Якщо директива AllowOverride не встановлена ​​в 'None', apache намагатиметься відкрити .htaccess файли в кожній директорії яку він відвідує і у всіх директоріях вище неї. наприклад:

Якщо буде запропоновано ввести відповідний /index.html, apache спробує відкрити (І інтерпретувати) файли /.htaccess, /var/.htaccess, /var/www/.htaccess, і /var/www/html/.htaccess. Це збільшує час обробки запиту. Так що, якщо вам потрібен .htaccess тільки для однією директорії, дозволяйте його тільки для неї:

FollowSymLinks і SymLinksIfOwnerMatch

Якщо для директорії включена опція FollowSymLinks, сервер буде слідувати за символічними посиланнями в цій директорії. Якщо для директорії включена опція SymLinksIfOwnerMatch, apache буде слідувати за символічними посиланнями тільки якщо власник файлу або директорії, на яку вказує ця посилання збігається з власником зазначеної директорії. Так що при включеній опції SymLinksIfOwnerMatch apache робить більше системних запитів.

Крім того, додаткові системні запити потрібні коли FollowSymlinks НЕ ВСТАНОВЛЕНО. Т.ч. найбільш оптимальна ситуація для продуктивності - коли опція FollowSymlinks включена.

Content Negotiatio

Намагайтеся уникати content negotiaion.

MaxClients

Директива MaxClients встановлює максимальну кількість паралельних запитів, які буде підтримувати сервер. Apache НЕ буде породжувати більше процесів / потоків ніж MaxClients. Значення MaxClient НЕ долно бути занадто маленьким (інакше багато клієнтів залишаться необслуженной), але і не варто встановлювати занадто велику кількість - краще НЕ обслужити частину клієнтів ніж вичерпати всі ресурси, залізти в своп і померти під навантаженням. Хорошим може бути значення MaxClients = кількість пам'яті виділене під веб-сервер / максимальний розмір породженого процесу або потоку. для статичних файлів apache використовує близько 2-3 Мб на процес, для динаміки (php, cgi) - залежить від скрипта, але зазвичай близько 16-32 Мб.

якщо сервер вже обслуговує MaxClients запитів, нові запити потраплять в чергу, розмір якої встановлюється за допомогою директиви ListenBacklog.

MinSpareServers, MaxSpareServers, і StartServers

Оскільки створення потоку, і особливо процесу - дорога операція, apache створює їх заздалегідь. Директиви MaxSpareServers і MinSpareServers встановлюють як багато процесів / потоків повинні очікувати в готовності прийняти запит (максимум і мінімум). Якщо значення MinSpareServers занадто маленьке і несподівано приходить багато запитів, apache змушений буде створювати багато нових процесів / потоків, що створить додаткове навантаження в цій стресовій ситуації. З інший боку, якщо MaxSpareServers занадто велике, apache буде сильно навантажувати систему цими процесами, навіть якщо кількість клієнтів мінімально.

Постарайтеся встановити такі MinSpareServers і MaxSpareServers, щоб apache не створював більше 4 процесів / потоків в секунду. Якщо він створить більш 4, в ErrorLog буде надруковано повідомлення про це. Це - сигнал того що MinSpareServers занадто мало.

MaxRequestsPerChild

Директива MaxRequestsPerChild встановлює скільки запитів може обробити один дочірній процес / потік перш ніж він буде завершений. За замовчуванням значення цієї директиви встановлено в 0, що означає що одного разу створений процес / потік не буде завершено ніколи (ну крім випадків зупинки сервера або краху цього процесу / потоку). Рекомендую встановити MaxRequestsPerChild рівне якомусь досить великій кількості (кілька тисяч). Це не створить зайвого навантаження, пов'язаної з тим що apache буде змушений створювати нові дочірні процеси, в той же час це допоможе позбутися від проблем з витоком пам'яті в дочірніх процесах (що дуже можливо наприклад якщо ви використовуєте нестабільну версію php).

KeepAlive і KeepAliveTimeout

KeepAlive дозволяє робити кілька запитів в одному TCP-підключення. Це особливо корисно для html-сторінок з великою кількістю зображень. Якщо KeepAlive встановлений в Off, то для самої сторінки і для кожного зображення буде створено окреме підключення (яке потрібно буде обробити master-процесу), що погано і для сервера і для клієнта. Так що для подібних випадків рекомендується встановлювати KeepAlive в On. Для інших застосувань (наприклад для download-сервера) KeepAlive може бути потрібен і навіть шкідливий, тому що при включеному KeepAlive сервер закриває з'єднання не відразу, а чекає KeepAliveTimeout секунд нового запиту. Для того щоб процеси не висіли занадто довго в непотрібному очікуванні, встановлюйте KeepAliveTimeout досить малим, близько 5-10 секунд зазвичай достатньо.

стиснення

HTTP-стиснення було визначено в стандарті HTTP / 1.1, і зараз всі сучасні клієнтські програми і практично всі сервера його підтримують. сервер може віддавати відповідь в gzip або deflate, а клієнтська програма непомітно для користувача розтискає дані. Це зменшує кількість переданого трафіку (до 75%), але звичайно ж підвищує використання процесора.

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

Кешування конфигурируется директивами модуля mod_deflate. Майте на увазі, що не слід встановлювати ступінь стиснення gzip більше 4-5 - це зажадає істотно більшого часу CPU, а ефект буде досить невеликий. Ну і зрозуміло не потрібно намагатися стиснути зображення в jpg, gif та png, музику, відео файли і всі інші бінарні файли, які вже і так добре стиснуті.

Кешування на стороні клієнта

Не забувайте встановлювати Expires заголовки на статичні файли (див. Модуль mod_expires). якщо файл не змінюється, то його завжди слід спробувати закеширувати на клієнті. тоді у клієнта будуть швидше завантажуватися сторінки, а сервер звільниться від зайвих запитів.

Відмінна стаття, передрукував з сайту Highload Web .

Ще записи по темі