[winrid]

Bad deployment system. You should do an A/B deployment and warm up the services/caches before the switch, so that the architecture handles the problem and not the programming language/VM.

At FastComments we run our E2E tests on the new instance to JIT the app. Before the Jit API calls can take 100ms, and after 10-30ms. Still, that is fast enough that most people wouldn't notice...

Also, the problem is not Java. Your application probably has way too many abstractions for a simple login page.

[xg15]

But why all the complexity?

There is a huge DI framework full of reflection and proxy classes, then a complex JIT to make the framework performant and now finally a scheduled warmup/load test phase to make the JIT work.

It seems like the same or better performance could be archieved with far less complexity by using an AOT compiled language.

[SureshG]

> with far less complexity by using an AOT compiled language.

Or use reflection free frameworks like Micronaut or Quarkus and enjoy the same productivity. The culprit here is no java, the spring framework.

[winrid]

Well I wouldn't use Spring, so that solves a lot of the problems... :)

I was never really a fan of DI.

Part of my point is your application should be fast enough before the JIT kicks in.

Ideally, you should also do performance testing. Incorporating that with your release go or no go is a great approach, IMO, if you do releases very often.

[brundolf]

> But why all the complexity?

Because it's probably a whole lot less work to add this new deployment mechanism than to completely change languages. Even for new projects there are tons of other things to factor in when picking a language; a crutch in one area can sometimes be the right call.