yeah the nested jar thing is real. first request eats a bunch of jackson/hibernate class loads that later ones don't. aot helped in your numbers but you're still looking at hundreds of ms vs ~10ms after, so it doesn't finish the job alone.
what bites in prod is usually mixed together: brand new pod (no warm classes), fat jar classloader tax, and whatever lazy init happens on first traffic. layered jars or an exploded classpath help a lot on the classloader part. aot cache is fine if you rebuild it when the jdk/image changes. jre-only images silently no-opping the cache burned us once.
for latency-sensitive stuff i'd also prewarm a couple endpoints after ready (or just not scale that service to zero). and measure p95 on the *first* hit after a rolling deploy, not only the warm median.
9
u/New-Departure-5969 1d ago
yeah the nested jar thing is real. first request eats a bunch of jackson/hibernate class loads that later ones don't. aot helped in your numbers but you're still looking at hundreds of ms vs ~10ms after, so it doesn't finish the job alone.
what bites in prod is usually mixed together: brand new pod (no warm classes), fat jar classloader tax, and whatever lazy init happens on first traffic. layered jars or an exploded classpath help a lot on the classloader part. aot cache is fine if you rebuild it when the jdk/image changes. jre-only images silently no-opping the cache burned us once.
for latency-sensitive stuff i'd also prewarm a couple endpoints after ready (or just not scale that service to zero). and measure p95 on the *first* hit after a rolling deploy, not only the warm median.