Привіт друзі! Минулого тижня обіцяв розказати про свіжий гейзенбаг, що ми недавно відловили в нашому проєкті. Може інформація стане комусь в нагоді. Чи просто розважить.
Отже, є в нас один продукт – розподілена система. Коли користувач робить в ній “певну дію”, система А формує запит до системи С, але не напряму, а через систему В (щось типу прокачаного проксі). А ➡️ B ➡️ C
В певний момент часу постала задача провести тестування навантаження продукту. І тест показав, що остання ланка, система С – сильно тормозить. Як в E2E тестах, так і напряму. Інформацію опрацювали, зробили оптимізацію та виділили більше ресурсів. Проблема не вирішилась взагалі, але її стало значно важче відтворити.
Аж ось через деякий час від користувачів приходить баг – при виконанні “певної дії” все тормозить! Порішайте!
Ми знову проводимо тести, бачимо, що система С тормозить, але щось трішки не сходиться – загальна продуктивність нижча за продуктивність системи С. Підключаємо моніторинг, дивимось веб запити і бачимо схему (як на картинці). Навіть у рідких випадках, коли система С обробляє все швидко – сумарний час запиту великий! І що це за проміжки між запитами? Такого точно немає бути згідно коду – опрацював запит – передай далі.
І ось приходить розуміння, що проблема навіть не одна, але все пов’язано з налаштуваннями.
❌ кожна система використовує скінченний connection pool – тобто на дію кожного користувача з пулу береться з’єднання і використовується для прийому/передачі даних, після чого з’єднання повертається в пул. Так от, коли одна з систем починала тупити, з’єднання не так швидко повертались в пул і навіть швидкі запити починали “тупити”, оскільки чекали вільного з’єднання. Справжня TCP пробка😄
❌ схожа ситуація була і з підключенням до БД – якщо системі треба було зчитати власні дані, а вільних підключень не було – система на них чекала 🤷♂️.
Збільшення з’єднань в налаштуваннях трохи збільшило ресурси, що використовуються системами, але значно зменшили затримки, а отже – збільшили продуктивність🤓
Ось так – ніякої магії. Дуже легко було без детального аналізу звинуватити одну систему в усіх гріхах, і дуже важко без спеціального софту і розуміння покращити якість.