Увімкнути KeepAlive чи ні?


9

Який консенсус щодо KeepAlive дотримується на високому сайті Magento? Здається, більшість людей рекомендують увімкнути його, але потім Magento заявляє, що це не потрібно використовувати для максимальної продуктивності та масштабованості з Magento Enterprise Edition, вони стверджують

"Коли веб-сервер перебуває під великим навантаженням, зберігання стійких з'єднань стає невигідним, тому директива KeepAlive завжди повинна бути відключена"

Думки?

Відповіді:


4

Чудове запитання!

Традиційно KeepAlive був гарною справою, оскільки він значно зменшує накладні витрати TCP загального завантаження сторінки, де багато запитів (як і всі зображення, css, js) подаються з одного сервера. Якщо на вашій сторінці 85 активів, це 85 додаткових тристоронніх рукостискань TCP, а затримка збільшується. Багато років тому при повільніших підключеннях до Інтернету це було набагато важливіше, ніж зараз, хоча воно все ще досить актуально для мобільних браузерів або будь-яких повільних / високих затримок.

Вплив, згаданий тут, хоч і стосується кількості часу, коли ці з'єднання TCP залишаються відкритими, і чи може це швидко вичерпати ваші дочірні процеси Apache. Більшість за замовчуванням, які я бачив, це:

KeepAliveTimeOut 15
MaxClients 256

Це означає, що якщо я мав 256 різних браузерів запитувати вміст протягом тих же 15 секунд, то 257-му клієнту доведеться чекати, коли з'єднання припиняться. Не добре - це взагалі не особливо великий трафік, тому це пояснює таку пораду. Це також може призвести до збільшення MaxClients, щоб впоратися, що може з'їсти багато пам'яті. Коли я використовую KeepAlives, я зазвичай встановлюю KeepAliveTimeout 2 або 3 секунди; це час простою між запитами, а не весь час для всіх запитів.

Якщо ви використовуєте KeepAlive, існує акт балансування між KeepAliveTimeout, MaxClients та серверними ресурсами. Щоб допомогти у цьому, "сервіс httpd / apache2 fullstatus" покаже вам кількість підключень, які використовує KeepAlives за будь-який час - вказується великим регістром "K".

Щодо Magento, я не думаю, що вам потрібен KeepAlives.

Що ви повинні робити, якщо у вас дуже високий трафік сайту Enterprise, використовується CDN для статичного вмісту.

Якщо ви продаєте в багатьох країнах, використання CDN не тільки прискорить загальне завантаження сторінок для ваших клієнтів (що добре), але й значно зменшить пропускну здатність, що надходить на ваш сервер. Налаштування в розділі Система> Налаштувати> Веб> [Зняти захищений) дозволяють інтегрувати будь-який CDN для медіа, шкіри та JavaScript. Це буде основна частина фактичних запитів HTTP, і в якості бонусу ви можете використовувати різні записи DNS для паралельного завантаження через імена хостів. Якщо ви робите це правильно, ці запити ледь торкаються вашого сервера, тому реальної потреби вже немаєдля KeepAlive. У цьому випадку слід відключити KA; ми не хочемо підтримувати зв’язок в прямому ефірі, коли знаємо, що решта вмісту подається десь з іншого місця. Якщо ви хочете отримати окрему рекомендацію CDN: CloudFlare - це фантастично, і ви навіть отримуєте SSL, переданий безкоштовним пакетом.

Якщо ви використовуєте подібний CDN або якщо ви використовуєте будь-який інший тип зворотного проксі (наприклад, Varnish), ваш Apache HTTP KeepAlives в основному не має значення.

Підводячи підсумок, я погоджуюся, що вам, мабуть, слід відключити KeepAlive, щоб уникнути насичення процесів Apache під навантаженням, але обов'язково використовувати CDN або інший зворотний проксі-сервер для активів, щоб зберегти завантаження сторінки якомога швидше.


1
Кипаливи залишаються актуальними під час виведення походження з CDN. Увімкнення / вимкнення не слід сприймати серйозно і слід ретельно перевірити. Я б прихильник зменшення запитів, зменшення ресурсів, перш ніж навіть розглянути CDN - неправильно налаштований, вони можуть зробити магазини повільніше, ніж швидше.
Бен Лессані - Сонассі

Як встановити цю локальну систему налаштування для сервера XAMPP?
Bhavin Thummar
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.