Затримки при обробці запитів після перезапуску (cold start JVM)
Привіт! Мене звати Сергій, і в мене є питання про Java. Я задав його на своєму каналі Мамкін Архітектор, проте розумні люди порадили написати також і тут, а з розумними людьми краще не сперечатись. Тому — питання:
Є кубер кластер з java сервісами, які виставляють назовні HTTP ендоінти. Там реплікасети, усі проби — наче все по красоті. Проте під час деплойменту спостерігаються спайки по часу відповіді. Буквально перші запити підвисають, а потім все ок.
Такий собі «холодний старт». І чомусь така поведінка позиціонується, як by design, і наче нічого (от прямо зовсім нічого) з цим не можна зробити.
Я шось такого ніде більше не бачив. В .NET наприклад (з яким в мене досвід є, і воно близьке до JVM) таких проблем не було. Звісно, потрібен час на прогрів апки, підтягнути усі залежності, завести кеші тощо. Проте якщо повісити readiness пробу на якийсь ендпоінт, то перші запити можуть бути довгими, але трафік піде лише коли вони закінчаться.
У випадку з Java таке враження, що кожен окремий ендпоінт треба прогрівати окремо. Мені це звучить якось дивно, як і те, що нема готового рішення.
Невже Netflix зі своїм мільйоном мікросервісів нічого не придумали? Напишіть бумласка, чи це правда і шо робити. Якщо не знаєте, то підписуйтесь на цей тред і канал, аби не пропустити правильну відповідь :)
3 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарівstartupProbe в якому кешується все що потрібно закешуватись — при респонзі 200 на пробу куб тільки тоді починає роутити запити на цей под
Перед тим як дивитися в сторону AOT/CDS/GraalVM.
Подивіться що у вас під час перших запитів не відбувається ініціалізація чогось важкого, наприклад: якийсь bean, котрий грузить кеш, позначений як lazy
Задвичай, після (як частина) деплойменту робиться smoke testing, де виконуються «перші запити, які підвисають».
Можна скомпілювати у native через graalvm — отримаєте швидкий старт зразу, за рахунок меншого перформансу потім.
Також цілком можливо, що воно у вас так зроблено спеіально — DI, lazy loading, багато ініціалізаціїї у рантаймі.