I'm running compojure on Heroku. They have a limit of a 100 threads per process. So when I go over that limit, I get: java.lang.OutOfMemoryError: unable to create new native thread.
Compojure is using the jetty ring adapter. Is there away of configuring the the server to only accept a hundred threads to the servlet at a time?
The solution comes from Chris Perkins over at the compojure google group.
(run-jetty app {:configurator #(.setThreadPool % (QueuedThreadPool. 5))})
This initializes a QueuedThreadPool (with a concurrent limit of five threads) to the jetty instance, before it starts.
Related
I have a microservice using spring boot 2.7.0 with embedded NIO tomcat. The application is responsible for receiving requests and for each request it makes 6 parallel remote calls waits at most 2 seconds for response from any of the 6 requests.
While performance testing this microservice using jmeter I observed that the CPU remains under-utilised around 14-15% but the microservice's response time increases to more than a minute. Typically it shouldn't be more than 2-3 seconds.
There are 3 thread configurations in my microservice:
Tomcat threads here I tried various configuration of maxthreads, maxconnection,accept-like (5000,30000,2000), (500,10000,2000), (200,5000,2000) but the CPU is always under-utilised. Here are the properties I am changing
server.tomcat.max-threads=200
server.tomcat.max-connections=5000
server.tomcat.accept-count=2000
server.connection-timeout=3000
For each request received we create a ForkJoinPool with parallelism as 6 to make the 6 remote calls. We tried using an ExecutorService too with different configuration like newSingleThreadExecutor,newCachedThreadPool,newWorkStealingPool. Also increased pool size to around same as maxThreads of tomcat and beyond but the result was same CPU still underutilized but microservice taking more than a minute to respond.
On logging the active thread count here we saw that no matter how much thread pool size or tomcat maxthreads we increased the, active thread count went upto 300 then start declining. We tried with a 4core 8GB system and 8core 16GB system results were exactly same
For making remote calls we use spring rest template with maxConnTotal and maxConnTotalPerRoute same as maxthreads of tomcat. maxConnTotal and maxConnTotalPerRoute are same because all 6 remote calls are to the same server.
Here are the jmeter parameters used -GTHREADS=1000 -GRAMP_UP=180 -GDURATION=300
There are 3 instances of this microservice running, roughly after 2-2.5 minutes after jmeter starts, all 3 instance's response time goes beyond a minute for all requests while CPU remains at 14-15% only. Could someone please help figure out what CPU is not spiking if CPU would spike to 35% then autoscaling would kick in but since CPU is under-utilised no scaling is happening
Use a profiler tool like VisualVM, YourKit or JProfiler to see where your application spends the most time
CPU is not the only possible bottleneck, check Tomcat's connection pool utilization as it might be the case the requests are queuing up, memory usage, network usage, database pool usage, DB slow queries log and so on. If you don't have a better monitoring software or an APM tool in place you can consider using JMeter PerfMon Plugin
We replaced RestTemplate for remote calls with WebClient and introducted WebFlux Mono to make the complete request non-blocking. The request itself now returns our response wrapped in Mono. It solved our issue now there is no idle time as threads are not blocked on IO rather they are busy serving other requests.
I have deployed my application in tomcat 7. I am using the default number of threads in thread pool. When I am running the performance testing for 500 concurrent users the application is not responding. I am using vCPU-8 and 16GB RAM EC2 instance.
Can any one suggest how to decide the number of threads in the thread pool? Also Is it possible to allocate fixed number of threads for a specific url prefixes?
Please note that it is not possible to horizontal scale the infrastructure because of limitations in the framework.
I am new to jmeter.
I am doing load testing on web application using recording feature in jmeter.
The issue is, If I'm giving say 100 with 100s ramp up time in Thread pool for 50 continuous web requests(sequence of web application flow).
If the server is not responding at 25th request(total 50) of 45th Thread(total 100) it is stuck at that point and not sending requests for remaining 55 threads.
What should I do.? is there any other method to initiate the threads.
it is not sending the threads because of many reasons
1. jmeter memory print you need to check
2. the server you are targeting will accept only no of threads.
etc are there.
if each thread processing time will take x amount of time hence n threads with x amount of time the processor is busy .
if your targeting server can only process 40 in this case i am assuming capacity as 40 , then the 41st request will only get chance , only at least one of the previous request get processed or released the thread .
too many threads might cause STUCK or BLOCKED threads at the server end in that case we either dont see response or error code . try stopping the threads you see all the reaming as failed requests
JMeter shouldn't normally act like you described. Check out jmeter.log file, it usually should have enough information to get to the bottom of problem.
It looks like you're trying to run the load test using JMeter GUI. If it's the case - please don't, JMeter is not designed for producing high load in GUI mode.
Run your test in command-line mode
Delete or disable Listeners if any
Increase JVM Heap size, JMeter comes with very little value by default.
Follow other recommendations from 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure article
If I have a server with 1 core, how many puma workers, threads and what database pool size is appropriate?
What's the general thumb here?
Not an easy answer.
The two main sources of information are:
Puma github repository (the authors' point of view)
Heroku's web page (the main big user's point of view)
Unfortunately they are inconsistent mostly because heroku has different deployment metrics and terminology.
So I ended up following the puma repository guidelines which says:
One worker per core
Threads to be determined in connection with RAM availability and application and
Threads = Connection Pool
So the number of threads is mostly a try and check operation.
I find that WCF service will take 8-10 seconds to load the first hit. After that it will take less than a second.
Any thoughts?
Probably due to .NET's cold start. Have you looked at setting up the IIS Warmup Module which initializes dependancies before an initial request?
From the Learn IIS website
Decrease the response time for first requests by pre-loading worker processes. The IIS Application Warm-Up module lets you configure the Web application to be pre-loaded before the first request arrives so that the worker process responds to the first Web request more quickly.
Increase reliability by pre-loading worker processes when overlapped recycling occurs. Because the recycled worker process in an overlapped recycling scenario only communicates its readiness and starts accepting requests after it finishes loading and initializing the resources as specified by the configuration, pre-loading the dependencies reduces the response times for the first requests.
Customize the pre-loading of applications. You can configure the IIS Application Warm-Up module to initialize Web applications by using specific Web pages and user identities. This makes it possible to create specific initialization processes that can be executed synchronously or asynchronously, depending on the initialization logic. In addition, these procedures can use specific identities to ensure a proper initialization.