Spring Native don't change performance (sometimes native image performance is even worse than JVM-based version). It improves startup time, that's it.
Claiming that Spring performance is "high" is like claiming that "3" is "many". Yes, in some circumstances "3" might be "many", but usually it's just "few". Same is with Spring, which is full of performance-killing solutions like abuse of run-time reflection.
@siy, I didn't know the native image could be worst than JVM 😯
If you think of a microservice architecture, a solution deployed on Kubernetes will scale horizontally faster with native image and that's something good to have.
I am the kind of person that a half water glass 🥃 is almost full 😅
Yes and no. Instead of applying "microservice architecture" patterns blindly, let's look why you need to scale it and scale quickly. And here appears the problem: you need to scale it because initial performance is very bad. And you need to scale it quickly because, besides bad performance, overload handled even worse - Spring (to be precise - Tomcat) nearly stops handling requests. In microservice setup this is especially bad, because whole setup is not fault tolerant (despite advertising). So, deploying new instances quickly is the only way to mitigate the issue at least partially.
Besides much better performance, modern asynchronous solutions (no, Spring Web Flow is not one of them) handling overload much better, gradually increasing response time and sustaining throughput. This means that new instances have enough time to start. And number of necessary instances is much lower - i.e. handling of the same load is cheaper and causes lower impact on the environment.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Why use a tool which lies starting from the front page?
And then you see first option "Spring Boot". High performance? Really?
Hi @siy 👋
Thank you for sharing your opinion 🤗
I agree that Spring Boot isn't the highEST performance technology, but for sure it's a high performance depending on your solution design and goal.
Things are getting better with Spring Native for JHipstee
Spring Native don't change performance (sometimes native image performance is even worse than JVM-based version). It improves startup time, that's it.
Claiming that Spring performance is "high" is like claiming that "3" is "many". Yes, in some circumstances "3" might be "many", but usually it's just "few". Same is with Spring, which is full of performance-killing solutions like abuse of run-time reflection.
@siy, I didn't know the native image could be worst than JVM 😯
If you think of a microservice architecture, a solution deployed on Kubernetes will scale horizontally faster with native image and that's something good to have.
I am the kind of person that a half water glass 🥃 is almost full 😅
Yes and no. Instead of applying "microservice architecture" patterns blindly, let's look why you need to scale it and scale quickly. And here appears the problem: you need to scale it because initial performance is very bad. And you need to scale it quickly because, besides bad performance, overload handled even worse - Spring (to be precise - Tomcat) nearly stops handling requests. In microservice setup this is especially bad, because whole setup is not fault tolerant (despite advertising). So, deploying new instances quickly is the only way to mitigate the issue at least partially.
Besides much better performance, modern asynchronous solutions (no, Spring Web Flow is not one of them) handling overload much better, gradually increasing response time and sustaining throughput. This means that new instances have enough time to start. And number of necessary instances is much lower - i.e. handling of the same load is cheaper and causes lower impact on the environment.