I have login API developed in spring boot and deployed on cloud run with min instance 1. But for some request it is taking 20s to process which is not desirable. When I checked logs, I found that application is starting again and it is taking time and most of request are processed within 100ms .Please suggest where Im going wrong.
I found that it was a cold start problem so kept min instance to 1. But still for some request it is taking more time than expected.
Related
When I checked the Eureka Dashboard, I confirmed that the application was terminated normally and was not displayed, but after that, it was routed to the terminated Spring application for about 30 seconds and gave a 500 error.
I think it's probably cached in eureka. I'd rather not be routed even for one second rather than a way to reduce the period.
Please let me know if there is any material or method that can help me thank you.
I don't want to be routed any more to Spring applications that are terminated in Spring eureka.
My application consists of a master spring boot application and 18 agents spring boot application. Each agent sending information to master for every 30 sec. However after some time master application processes messages that arrived like 10min before. when I restart master application, it works fine. I could not solve the problem. is anyone has idea what should I check
My application is a Rest API springboot +jersey based on microservice architecture Eureka.
The first call after instance start is slow comparing to the following calls (even though I stubbed the results).
Example of first call: 500ms, the other calls about 60-100ms.
Can anyone help me to resolve this issue?
Most likely, this is related to JVM warm up. From https://www.baeldung.com/java-jvm-warmup:
The first request made to a Java web application is often substantially slower than the average response time during the lifetime of the process. This warm-up period can usually be attributed to lazy class loading and just-in-time compilation.
I am using spring boot 2.0.4.RELEASE. My doubt is whether my application is running in event loop style or not. I am using tomcat as my server.
I am running some performance tests in my application and after a certain time I see a strange behaviour. After the request reaches 500 req/second , my application is not able to serve more than 500 req/second. Via prometheus I was able to figure out max thread for tomcat were 200 by default. Looks like all the threads were consumed and that's why , it was not able to server more than 500 req/second. Please correct me if am wrong.
Can the tomcat server run in event-loop style ?
How can I change the event-loop size for tomcat server if possible.
Tried changing it to jetty still the same issue. Wondering if my application is running in event loop style.
Hey i think that you are doing something wrong in your project maybe one of your dependency does not support reactive programming. If you want to benefit from async programing(reactive) your code must be 100 reactive even for security you must use reactive spring security.
Normally a reactive spring application will run on netty not in tomcat so check your dependency because tomcat is not reactive
This is more of a analysis. After running some performance test on my local machine , I was able to figure out what was actually happening inside my application.
What I did was, ran performance test on my local machine and analysed the application through JConsole.
As I said I scheduled all my blocking dB calls to schedulers.elastic. What I realised that I it is causing the bottleneck. since my dB connections are limited and I am using hikari for connection pooling so it doesn’t matter the number of threads I create out of elastic pool.
Since reactive programming is more about consuming resource to the fullest with lesser number of threads, since the threads were being created in unbounded way so it was no different from normal application .
So what I did as part of resolution limited the number of threads to 100 that were supposed to be used by for dB calls. And bang number jumped from 500 tps to 2300 tps.
I know this is not the number which one should expect out of reactive application , it has much more capability. Since right now I do not have any choice but to bear with non reactive drivers .Waiting for production grade availability of reactive drivers for mssql server.
the response time of my spring boot rest service running on embedded tomcat sometimes goes really high. I have isolated the external dependencies and all of that is pretty quick.
I am at a point that I think that it is something to do with tomcat's default 200 thread pool size that it reserves only for incoming requests for the service.
What I believe is that all 200 threads under heavy load (100 requests per second) are held up and other requests are queued and lead to higher response time.
I was wondering if there is a definitive way to find out if the incoming requests are really getting queued? I have done an extensive research on tomcat documentation, spring boot embedded container documentation. Unfortunately I don't see anything relevant.
Does anyone have any ideas on how to check this