Як знайти той один рядок, через який checkout повільний.
Коли магазин здається повільним, а сервери простоюють, очікування зазвичай є синхронним викликом до чужої системи всередині шляху запиту. Метод, який перетворює «здається повільним» на файл і рядок.
У цій статті 8 розділів
Скарги на те, що магазин повільний, належать до розмитого, репутаційного типу. Жодного stack trace, жодного номера рядка, лише торговець переказує, що так сказав покупець, і арифметика під цим: повільний checkout є покинутим кошиком, а покинутий кошик є доходом, що виходить за двері посеред покупки. Тож першою роботою є не виправити щось. А перетворити відчуття на місце.
- Вимірюйте платформу під навантаженням, що відмовляє, а не в тиху мить: CPU, навантаження, пам'ять, диск, на кожному рівні. Якщо кожен рівень простоює, очікування живе в застосунку або в тому, що він викликає.
- Не довіряйте кешованій головній сторінці. Її віддає CDN, і вона нічого не доводить про кошик і checkout, які виконують живий код застосунку при кожному запиті.
- Зберіть кожен запит, повільніший за поріг, і згрупуйте stack trace за тим, де кожен запит заблокований, а не де він почався. Одна група височіє над рештою, і зазвичай це синхронний виклик до системи, якою магазин не керує.
- Передайте точний файл, точний рядок і виправлення: короткий таймаут із запасним варіантом, зовнішній виклик, перенесений у фонове завдання, і запити під ним, проіндексовані так, щоб вони шукали, а не сканували.
Скарга надходить як відчуття
Формулювання репутаційне, а не технічне: покупець сказав торговцю, що сайт здавався повільним, і торговець передає це далі. Для магазину «повільний checkout» не є дрібницею: це кошики, покинуті на кроці оплати, у найдорожчому місці всього сайту, де можна когось втратити. Це задає терміновість, але нікуди не вказує. Повільно є відчуттям, а не місцем.
Тривога про ресурс каже вам, куди дивитися. «Сайт повільний» не каже нічого: це може бути мережа, хост, база даних, застосунок або третя сторона, якою магазин навіть не керує. Перш ніж ви зможете це виправити, ви маєте перетворити відчуття на номер рядка. Решта цієї статті про те, як.
Спочатку виміряйте платформу під навантаженням, що відмовляє
Почніть із платформи, виміряної під тим самим навантаженням, що відмовляє: CPU, середнє навантаження, вільна пам'ять, завантаження диска, на веб-рівні й на базі даних. Читайте їх, поки повільність відбувається, а не з панелі, усередненої за тихий тиждень. Якщо кожен рівень простоює, очікування живе в застосунку або в тому, що він викликає, і решта методу полягає в тому, щоб знайти, у чому саме.
Саме тут зупиняється багато діагнозів. «Це застосунок» є правдою і марним для торговця: це виправдовує хост і залишає магазин так само застряглим, як і раніше. Власник магазину не хоче знати, що це застосунок. Він хоче знати, який рядок і чому. Тож метод іде далі в код, який не нам виправляти, бо знайти рядок і є справжнім результатом.
Головна сторінка спробує це приховати
Перше, що показує вибіркова перевірка, виглядає заспокійливо, і в цьому пастка. Головна сторінка, кешована на CDN, повертається швидко. Якщо ви перевіряєте магазин, завантажуючи його головну сторінку, ви робите висновок, що все гаразд, і закриваєте тікет. Але кешована головна нічого не доводить про checkout, бо біль живе лише на шляхах, які неможливо кешувати: динамічний кошик і checkout, де магазин виконує свій справжній код при кожному запиті.
| Кешована головна сторінка | Шлях checkout |
|---|---|
| Віддається з edge CDN | Щоразу виконує живий код застосунку |
| ДЕ ЖИВЕ БІЛЬШвидка при кожній вибірковій перевірці | Там, де насправді живе кожна секунда очікування |
| Виглядає цілком здоровою | Її ніколи не торкається вибіркова перевірка головної |
Групуйте за місцем блокування, а не за початком
Крок, який усе відкриває, перетворює шум на зізнання. Замість того щоб вгадувати, зберіть кожен запит, повільніший за поріг, на всіх веб-вузлах, а потім згрупуйте stack trace за єдиним, що має значення. Не за тим, де кожен запит почався (усі вони починаються з URL), а за точним рядком, де кожен запит заблокований, сидить і чекає. Згрупуйте тисячі повільних запитів за точкою блокування, і вгадування закінчується. Одна група височіє над рештою, і в магазині це зазвичай живий вихідний виклик до системи, якою магазин не керує: перевірка залишків, пошук ціни, оцінка шахрайства, ERP, усередині валідації замовлення. Виклик до бази даних, що живить ту саму інтеграцію, зазвичай є наступною групою нижче.
Прочитайте один заблокований запит згори донизу
Стек заблокованого запиту показує весь ланцюжок від точки входу до зовнішнього виклику, на який він чекає: кнопка оплати нагорі, валідація замовлення посередині, а внизу виклик до машини в іншій мережі, де запит сидить, доки та машина не відповість. Саме цю картину варто показати торговцю, бо вона не потребує тлумачення: людина, яка намагається дати магазину гроші, чекає на систему, якою магазин не керує, перш ніж замовлення взагалі пройде валідацію.
Потім прочитайте конфігурацію клієнта для цього виклику. Стелею очікування є один рядок: його таймаут. Таймаут клієнта, заданий у хвилинах, там, де платіжному шляху потрібні секунди, означає, що покупця можна тримати біля кнопки оплати стільки, скільки партнер відповідає, і повільний день партнера стає днем магазину.
“Покупець, який намагається заплатити, чекає на машину, якою магазин не керує, у мережі, якою магазин не керує, перш ніж замовлення взагалі пройде валідацію.”
Перевірте запити під ним
Slow log бази даних зазвичай вказує на ту саму інтеграцію: запити, що її живлять, сканують замість того, щоб шукати, і стоять на тому самому шляху. Зовнішній виклик повільний, запити під ним повільні, і обидва стоять між покупцем і замовленням. Виправлення виклику без запитів залишає друге вузьке місце на місці.
Ми не переписуємо ваш checkout. Ми вручаємо вам рядок.
Ми не переписуємо checkout клієнта: це його код, його бізнес-логіка, його ризик. Те, що ми передаємо, корисніше й важче здобути: точний файл, точний рядок і конкретне виправлення. Три кроки, по порядку.
Обмежте таймаут.
Скоротіть таймаут до кількох секунд із м'яким запасним варіантом, щоб повільний партнер погіршував одне число залишків замість того, щоб заморожувати всю оплату.
Приберіть його зі шляху запиту.
Перенесіть зовнішній виклик із живого запиту у фонове завдання. Оплата покупця не має чекати, наживо, на відповідь третьої сторони.
Виправте запити під ним.
Проіндексуйте й перепишіть запити, що живлять інтеграцію, щоб дані за нею перестали бути другим вузьким місцем.
- Живий виклик до зовнішньої системи всередині валідації замовлення
- Таймаут, виміряний у хвилинах, на кроці оплати
- Покупець чекає біля кнопки оплати
- Повні сканування таблиць, що виконуються разом із checkout
- Зовнішній виклик перенесений у фонове завдання
- Таймаут у кілька секунд із м'яким запасним варіантом
- Кнопка оплати відповідає у власному бюджеті платформи
- Запити проіндексовані й переписані
Урок
Здоровий простоюючий сервер майже ніколи не є місцем, де живе повільність. Коли платформа спокійна, а покупець чекає, очікування є в рівні застосунку або в тому, що він викликає, і метод вище знаходить, у якому рядку.
Тримайте синхронні виклики третіх сторін поза шляхом запиту. Дайте зовнішнім системам короткий таймаут і запасний варіант, а справжню роботу виконуйте у фоновому завданні. Шлях запиту належить покупцю.
Прямі відповіді
Чому мій checkout повільний, коли решта сайту швидка?+
Зазвичай тому, що швидка частина кешована, а повільна ні. Головна сторінка, яку віддає CDN, відповідає швидко і нічого не каже про checkout, який виконує ваш живий код застосунку при кожному запиті, включно з будь-яким викликом третьої сторони на платіжному шляху. Перевіряйте динамічний кошик і checkout, а не головну.
Повільний checkout є проблемою хостингу чи застосунку?+
Це варто довести, а не припускати. Виміряйте веб-рівень і базу даних під тим самим живим навантаженням: CPU, навантаження, пам'ять, диск. Якщо нічому не бракує ресурсів, очікування є в застосунку або в тому, що він викликає, і наступний крок полягає в тому, щоб зібрати повільні запити й прочитати, де вони блокуються.
Що таке синхронний виклик третьої сторони на шляху checkout?+
Це коли ваш checkout блокується й чекає, наживо, на зовнішню систему, перш ніж дозволити замовленню пройти далі: ERP, сервіс залишків, оцінка шахрайства, що перевіряються всередині валідації замовлення. Якщо цей партнер повільний, ваш покупець чекає рівно стільки ж, до налаштованого таймауту, а таймаут у хвилинах є стелею, виміряною у хвилинах.
Як знайти, який рядок робить сторінку повільною?+
Зберіть кожен запит, повільніший за поріг, на всіх веб-вузлах, а потім згрупуйте stack trace за точним рядком, де кожен запит заблокований, а не де він почався. Найбільша група є вашою відповіддю.
Чи виправите ви мій код за мене?+
Ми не переписуємо ваш checkout: це ваша бізнес-логіка. Ми вручаємо вам точний файл, точний рядок і конкретне виправлення: скоротити таймаут із запасним варіантом, перенести виклик третьої сторони у фонове завдання, а повільні запити під ним ми проіндексуємо й перепишемо. Діагноз, переданий точно, і є продуктом.
Чи має кнопка оплати викликати ERP або іншу третю сторону напряму?+
Тримайте це поза шляхом запиту. Система на інфраструктурі, яку ви не контролюєте, не має стояти між покупцем і оплатою. Дайте їй короткий таймаут і м'який запасний варіант, щоб вона могла відмовити, не поклавши checkout, і перенесіть справжній виклик у фонове завдання.
Щось у вашому checkout повільне. Ми знайдемо рядок.
Поговоріть з інженером, який прочитає ваш повільний шлях до файлу й рядка і прямо скаже, коли відповідь живе у вашому власному коді.
Поговоріть з інженеромДисципліна тут та сама, що й за двома іншими статтями: як діставатися до розміру сервера, де більшості людей потрібно менше, ніж їм здається, і чому новий сервер у бенчмарках повільніший за старий, хоча насправді ні.
Ви дійшли до кінця.
Застосуйте прочитане на практиці
Що ви запускаєте?
Розкажіть нам про навантаження, трафік і вимоги до відновлення. Почніть з конструктора сервера або обговоріть деталі з інженером.
Написано інженерами, які будують і експлуатують інфраструктуру, про яку йдеться.Поговоріть з інженером