Clarification on okhttp dispatcher thread pool max threads - okhttp

what is the max thread count for
1)dispatcher thread pool
2)MaxRequestsPerHost (dispatcher)
3)MaxRequests (dispatcher)

is builtin. No need to take care yourself.
5 concurrent requests per host.
64 concurrent requests.

Related

How can i run a load for 10 minutes with 500 transactions/sec with 25 concurrent users ? Is this a valid scenario to achieve in Jmeter

I have tried with concurrent users thread group pairing with throughput timer , but the transactions were low , Is there any other way to achieve the above scenario
#dmitri
I happened to use this function ${__tstFeedback(throughput-timer,25,2500,100)} in my concurrent thread group still I what could see is not more than 200 transaction/sec
Concurency thread group setup
Throughput shaping timer
Transactions per sec
I always see this additional request added to my summary and aggregate reports results Concurrency Thread Group-ThreadStarter:
Concurrency Thread Group-ThreadStarter: 15034 27152 314 67905 17924.575009281336 0.5485566050286018 27.972210128343956 101.83185588876516 3.662355576998932 3727.836304376746
It might be a valid scenario depending on your application response time.
In order to be able to achieve 500 requests/second with 25 users each user needs to be able to execute 20 requests per second which means that your application response time needs to be 50 milliseconds or less.
If response time is above 50 milliseconds the number of requests per second will reduce proportionally.
If you have more than 1 request in your transaction - the response time constraint changes correspondingly like 2 requests - 25 milliseconds max, etc.
JMeter's Constant Throughput Timer can only capable of pausing the threads to limit the number of transactions per minute to the given value, if the current amount is not enough - it won't kick off extra threads. So it's your job to provide sufficient number of threads in the Thread Group
As the alternative you can consider going for Throughput Shaping Timer and Concurrency Thread Group combination, they can be connected via Feedback Function so if current number of threads is not enough to reach/maintain the desired throughput - more threads will be launched

How to count thread running per second in Jmeter

I am so much confused with Jmeter test configuration. I found lots of answers but non those clear my doubt. My thread group contain 10 threads and all are in active state. I want to hit 20 requests per second to server. Load need to last for 60 seconds.
I put
thread count : 20
Ramp Up Period : 1
Loop Count: 60
Is it correct method to hit 20 requests/second last for 60 seconds?
For Request Per Second we should not calculate manually, instead leave the headache to JMeter. Just make sure, to have enough Threads to reach that TPS and JMeter will control the pacing. If the Threads are less and Request Per Second is more, than JMeter cant to anything and RPS wont be met.
Use Throughput Shaping Timer to achieve Request Per Second Throughput Shaping Timer
How Many Threads I Need To Produce Desired RPS?
Threads pool size can be calculated like RPS * <max response time> / 1000. The more rate desired the more threads you will need. The more response time service have the more threads you will need.
For example, if your service response time may be 2.5sec and target rps is 1230, you have to have 1230 * 2500 / 1000 = 3075 threads.
It is better to have some threads overhead to handle unexpected response time spikes. But beware of too much overhead, it will lead to "final spike".
Use Following settings in Thread Group and Throughput Shaping Timer:
Increase Number of Threads if 20 TPS is not met.
You can use stepping thread group or concurrency thread group instead of basic thread group to achieve your desired results.
https://jmeter-plugins.org/wiki/ConcurrencyThreadGroup/
Your configuration will be correct only if:
You have only one Sampler
It's response time is equal to 1 second
Correct configuration would be something like:
The best approach would be going for Concurrency Thread Group and Throughput Shaping Timer combination. They can be connected together via Feedback Function allowing the Concurrency Thread Group to kick off more threads if current amount is not enough to conduct the required load.

Jmeter: control the number of requests happening at one time

I'm doing performance testing on an app that does transactions.
I have 25 threads but only 5 unique IDs.
Here's my problem:
To avoid concurrency issue, I want to limit the number of requests being made during a buy/sell transaction to only 5 (cuz only 5 unique IDs). How do I achieve this in Jmeter?
Please be detailed in answer as i'm a total noobie. Thank you!!
You can limit the execution rate to the specified number of requests per unit of time using the following test elements:
Precise Throughput Timer
Constant Throughput Timer
Throughput Shaping Timer
All of them are capable of "pausing" JMeter threads to the specified throughput (# of requests per minute/second)
Use Synchronizing Timer
The purpose of the SyncTimer is to block threads until X number of threads have been blocked, and then they are all released at once.
With Number of Simultaneous Users to Group by as 5

JMeter - Achieving Desired Requests Per Second

I'm having trouble achieving the desired 'requests per second' using a combination of 'bzm - Concurrency Thread Group' and 'Constant Throughput Timer' in JMeter.
Structure
My test is structured as follows:
Thread Group 1
Constant Throughput Timer
HTTP Request
Thread Group 2
Constant Throughput Timer
HTTP Request
Thread Group 3
Constant Throughput Timer
HTTP Request
Thread Group 4
Constant Throughput Timer
HTTP Request
Numbers
I am wanting to achieve 160 concurrent users for each of the Thread Groups.
Thread Group 1 I am aiming to make 350 requests per second, the others are aiming for 160 requests per second.
The Thread Groups have 160 as the 'Target Concurrency'.
Constant Throughput Timer has 21000 for Thread Group 1 (350 rps*60 = 21000 per minute).
Constant Throughput Timer has 9600 for the others (160 rps*60= 9600 per minute).
All of them have 'Calculate Throughput based on: this thread only'
I'm currently only getting a throughput of around 80 rps for Thread Groups 2-4 and less than 10 for Thread Group 1.
I've allowed JMeter to use 4GB of RAM and I'm not using all of this during the test. When I remove all Throughput Timers, I can achieve up to 14k rps.
Am I missing something? Is there a better way to achieve my desired throughput?
The reasons of not achieving desired number of requests per second could be in:
You simply don't have enough threads in thread group
JMeter cannot send requests fast enough due to lack of resources on its side
Application under test cannot respond fast enough
With regards to point 1 be aware that Constant Throughput Timer can only pause threads in order to limit JMeter's throughput to the desired number of requests per minute.
Given you use Concurrency Thread Group it makes more sense to switch to Throughput Shaping Timer which can be connected to the Concurrency Thread Group via feedback loop so JMeter will be able to kick off extra threads to achieve the desired RPS rate.
You can install Throughput Shaping Timer using JMeter Plugins Manager
With regards to point 2: make sure you're following JMeter Best Practices and monitoring baseline OS health metrics on machine where JMeter is running, if there is lack of CPU or RAM you might need to consider Distributed Testing
With regards to point 3: the same approach as for point 2 + use profiling tools to see where application spends the most of time

How to change number of worker threads in finch/finagle?

I have a finch endpoint that works fine when sequential calls are made.in case of concurrent requests, service latency is increasing in the proportion of the number of concurrent requests.I have two questions regarding this.
Is blocking of thread causing latency problem?
How many worker threads are present in finch?
How to increase the number of worker threads?
How will the system affect after changing default worker thread count?
Blocking a Finagle thread is never a good idea. Normally you get 2 * CPU cores threads in your thread-pool. You can try overriding it with the -Dcom.twitter.finagle.netty4.numWorkers=48 flag.
Before tweaking the thread pool, I'd recommend looking into FuturePools for means to offload your blocking code from a Finagle thread.

Resources