You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I finally managed to create a Quarkus 3 native image of one of our microservices - it wasn't easy due to some weird compilation errors that didn't occur with the native Quarkus 2 build.
However, the aspect that remains a concern is the startup time - the best case scenario is 7.2secs with some startups taking just over 9 seconds.
AWS Lambda requires a maximum initialization time of less than 10 seconds, which doesn't leave a hell of a lot of headroom and there's a risk that there may be an occasional startup time error due to the 10 sec threshold.
Of course, once the function is "warm", the execution time is super fast - but it has to start up first in any case. And as we know even a warm function is recycled by AWS every 5ish minutes or so.
I can't pinpoint it, but I suspect that the panache/hibernate initialization is the prime candidate responsible for the long boot time.
Our scenario may be somewhat special because we require JTA, but the "naked" application code is quite compact (with some more heavy-weight third-party libraries, but it seems unlikely that these are responsible for the raw boot time - these libraries should have a passive initialization). We have about 47 @ApplicationScoped and 43 @entity in the app just to provide a complexity context.
Thus I wonder whether whether we are the only ones experiencing this slow startup time issue?
FWIW - we have already disabled some hibernate verification:
quarkus.hibernate-orm.database.generation=none
quarkus.hibernate-orm.validation.enabled=false
Is there a way to improve the (native) function readiness time from an initialization perspective? As in asynchronous initialization of panache, for instance?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I finally managed to create a Quarkus 3 native image of one of our microservices - it wasn't easy due to some weird compilation errors that didn't occur with the native Quarkus 2 build.
However, the aspect that remains a concern is the startup time - the best case scenario is 7.2secs with some startups taking just over 9 seconds.
AWS Lambda requires a maximum initialization time of less than 10 seconds, which doesn't leave a hell of a lot of headroom and there's a risk that there may be an occasional startup time error due to the 10 sec threshold.
Of course, once the function is "warm", the execution time is super fast - but it has to start up first in any case. And as we know even a warm function is recycled by AWS every 5ish minutes or so.
I can't pinpoint it, but I suspect that the panache/hibernate initialization is the prime candidate responsible for the long boot time.
Our scenario may be somewhat special because we require JTA, but the "naked" application code is quite compact (with some more heavy-weight third-party libraries, but it seems unlikely that these are responsible for the raw boot time - these libraries should have a passive initialization). We have about 47 @ApplicationScoped and 43 @entity in the app just to provide a complexity context.
Thus I wonder whether whether we are the only ones experiencing this slow startup time issue?
FWIW - we have already disabled some hibernate verification:
quarkus.hibernate-orm.database.generation=none
quarkus.hibernate-orm.validation.enabled=false
Is there a way to improve the (native) function readiness time from an initialization perspective? As in asynchronous initialization of panache, for instance?
Beta Was this translation helpful? Give feedback.
All reactions