Як ми готуємо новинний сайт до піку відвідуваності.
Бізнес новинного сайту складається з піків. Ось метод, яким ми готуємо його до них: читати правильні логи, знати, де стеля, перевіряти кожен рівень до того, як витрачати, і рахувати.
У цій статті 4 розділів
- Трафік виявляє стелі; стелі задає конфігурація. Підготуватися до піку означає знайти їх раніше, ніж це зробить аудиторія.
- Спершу підтвердьте, який лог насправді містить трафік сайту. Типовий лог сервера може тримати малу частку, тоді як власний лог vhost сайту тримає решту.
- Перевірте кожен рівень до того, як витрачати. База даних часто простоює і відповідає швидко, тоді як робота стоїть у черзі на рівень вище.
- Потім арифметика: workers, поділені на секунди на запит, є вашою реальною стелею в запитах за секунду. Розрахуйте пул на пік, якого ви справді досягнете, плюс запас.
Бізнес новинного сайту складається з піків: коли з’являється новина, аудиторія приходить уся одразу. Підготовка до цього рідко є питанням обладнання. Це питання конфігурації: кількість workers, тайм-аути, логи, кеш. Ось як ми його готуємо.
Спочатку читайте правильний лог
Перша дисципліна полягає в тому, щоб рахувати правильно. На типовому веб-сервері типовий лог і власний лог vhost сайту є різними файлами, і типовий може містити лише малу частку трафіку. Розрахуйте щось за неправильним логом, і ви розрахуєте це на неправильне навантаження.
Знайте, де стеля
Під навантаженням час відповіді на запити показує, де межа. Органічна повільність розсіяна: деякі запити трохи повільні, деякі дуже повільні. Повільні запити, що скупчуються рівно на тайм-ауті шлюзу, означають, що рівню за шлюзом бракує workers у межах його бюджету. Це сигнатура насичення, і вона вказує прямо на параметр, який треба розрахувати.
Перевірте кожен рівень до того, як витрачати
Перш ніж хтось купить RAM чи оновить рівень даних, перевірте його. База даних, яка простоює і відповідає швидко, без повільних запитів, відповідаючи на все тієї ж миті, коли її питають, не є рівнем, який треба розраховувати. Розраховувати треба той рівень, у якого всі workers зайняті. Цей патерн має власний допис: зменшуйте, а не збільшуйте.
Ваша стеля є арифметикою
WORKERS
SEC / REQUEST
REQ / SEC
Підготовка є розрахунком, а не закупівлею: пул workers, обчислений з піку, якого новинний сайт справді досягне, плюс запас, у межах виміряного бюджету пам’яті на кожен worker. Потім рівень кешу, який віддає застарілий вміст, коли backend сповільнюється, щоб зайнятий backend деградував до трохи старих сторінок замість сторінок з помилками. Платформа поглинає пік.
“Трафік знаходить стелю, яку ви задали. Задавайте її навмисно.”
Прямі відповіді
Чому сайт видає помилки 502 під великим трафіком?+
Зазвичай рівню за шлюзом бракує workers, і шлюз здається на своєму тайм-ауті. Сигнатура: повільні запити, прибиті рівно до одного числа. Спершу порахуйте помилки у правильному лозі vhost, бо типовий лог може містити лише частку вашого трафіку.
Скільки workers має мати мій сервер застосунків?+
Обчисліть: workers, поділені на середню кількість секунд на запит, є вашою стелею в запитах за секунду. Розраховуйте на пік, якого ви справді досягнете, плюс запас, у межах виміряного бюджету пам’яті на worker, замість того, щоб довіряти типовому значенню пакета.
Чи є база даних вузьким місцем, коли трафік стрибає?+
Перевірте до того, як витрачати. Подивіться, простоює вона чи зайнята і чи є повільні запити. Часто база даних простоює і відповідає швидко, а робота стоїть у черзі на рівень вище. Спершу перевірте кожен рівень.
Як підготувати сайт до піку трафіку?+
Порахуйте workers відносно вашого реалістичного піку, підтвердьте, які логи справді містять ваш трафік, проведіть навантажувальне тестування до обчисленої стелі і поставте попереду кешування stale-on-error, щоб повільний backend віддавав старі сторінки замість помилок.
Хіба більше трафіку не вимагає просто більше серверів?+
Зрештою так, але майже ніколи не в першу чергу. Спершу використайте ємність, яку стримує ваша конфігурація: правильно розраховані пули, розумні тайм-аути, кешування, що поглинає шторм читань. Обладнання, куплене, щоб прикрити параметр конфігурації, є найдорожчою зміною конфігурації з усіх.
Очікуєте свій найкращий день найближчим часом?
Запуск, преса, сезонний пік: назвіть нам дату. Ми порахуємо workers, прочитаємо правильні логи і зробимо пік просто ще одним графіком.
Поговоріть з інженеромВи дійшли до кінця.
Застосуйте прочитане на практиці
Що ви запускаєте?
Розкажіть нам про навантаження, трафік і вимоги до відновлення. Почніть з конструктора сервера або обговоріть деталі з інженером.
Написано інженерами, які будують і експлуатують інфраструктуру, про яку йдеться.Поговоріть з інженером