Затримки при обробці запитів після перезапуску (cold start JVM)

💡 Усі статті, обговорення, новини про Java — в одному місці. Приєднуйтесь до Java спільноти!

Привіт! Мене звати Сергій, і в мене є питання про Java. Я задав його на своєму каналі Мамкін Архітектор, проте розумні люди порадили написати також і тут, а з розумними людьми краще не сперечатись. Тому — питання:

Є кубер кластер з java сервісами, які виставляють назовні HTTP ендоінти. Там реплікасети, усі проби — наче все по красоті. Проте під час деплойменту спостерігаються спайки по часу відповіді. Буквально перші запити підвисають, а потім все ок.

Такий собі «холодний старт». І чомусь така поведінка позиціонується, як by design, і наче нічого (от прямо зовсім нічого) з цим не можна зробити.

Я шось такого ніде більше не бачив. В .NET наприклад (з яким в мене досвід є, і воно близьке до JVM) таких проблем не було. Звісно, потрібен час на прогрів апки, підтягнути усі залежності, завести кеші тощо. Проте якщо повісити readiness пробу на якийсь ендпоінт, то перші запити можуть бути довгими, але трафік піде лише коли вони закінчаться.

У випадку з Java таке враження, що кожен окремий ендпоінт треба прогрівати окремо. Мені це звучить якось дивно, як і те, що нема готового рішення.

Невже Netflix зі своїм мільйоном мікросервісів нічого не придумали? Напишіть бумласка, чи це правда і шо робити. Якщо не знаєте, то підписуйтесь на цей тред і канал, аби не пропустити правильну відповідь :)

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

startupProbe в якому кешується все що потрібно закешуватись — при респонзі 200 на пробу куб тільки тоді починає роутити запити на цей под

Невже Netflix зі своїм мільйоном мікросервісів нічого не придумали?

www.youtube.com/watch?v=XpunFFS-n8I

Перед тим як дивитися в сторону AOT/CDS/GraalVM.
Подивіться що у вас під час перших запитів не відбувається ініціалізація чогось важкого, наприклад: якийсь bean, котрий грузить кеш, позначений як lazy

Буквально перші запити підвисають, а потім все ок.

Задвичай, після (як частина) деплойменту робиться smoke testing, де виконуються «перші запити, які підвисають».

Такий собі «холодний старт». І чомусь така поведінка позиціонується, як by design, і наче нічого (от прямо зовсім нічого) з цим не можна зробити.

Можна скомпілювати у native через graalvm — отримаєте швидкий старт зразу, за рахунок меншого перформансу потім.
Також цілком можливо, що воно у вас так зроблено спеіально — DI, lazy loading, багато ініціалізаціїї у рантаймі.

Підписатись на коментарі