Given the following table :
I want to calculate the average waiting time of preemptive priority scheduling .
In the table above , the bigger the number is (in the priority column) the higher the priority is .
Partial solution :
|p1|p3|p1|p2|p5|p4|
0 8 29 33 52 67 80
What do I do from here ?
Thanks
did you understand the partial solution (the actual schedule) you have posted?
Waiting time of a process = finish time of that process - execution time - arrival time
Once you have this for all process then just take the average. That would give you the avg waiting time of the scheduling algorithm for this instance
More details:
Here process p1 did not wait for the first 8 seconds. Then at t=9 it was preempted. It was in wait mode from time t=9 to t=29 while process p3 was executing. So p1 had waited for 21 seconds while p3 was executing. At t=29, p1 started again and completed at t=33. In total, p1 had waited for 21 seconds. As per the formula we get waiting time as 33-12-0=21. Basically for each process we look at the time between when it arrived and when it finished. Any time between this interval when it is not executing is a wait time
Related
I have 5 thread groups each one have 3 api requests and each thread should execute one after one, in 1 hour load test should achieve 120 hits per second.
Pacing: 5 sec
Thinktime: 8 sec
Each thread single iteration time: 20 sec
So for this how much users I need to give to achieve required 120 hits per second and how can I do load test for 5 thread groups because each one should execute one after one.
It's a matter of simple arithmetic calculations and I believe question should go to https://math.stackexchange.com/ (or alternatively you can catch a student of the nearest school ask ask him)
Each thread single iteration time: 20 sec
means that each user executes 3 requests per 20 seconds, to wit 1 request per 6.6 seconds.
So you need 6.6 users to get 1 request per second or 792 users to reach 120 requests per second.
Also "pacing" concept is for the the "dumb" tools which don't support setting the desired throughput and JMeter provides:
Constant Throughput Timer
Precise Throughput Timer
Throughput Shaping Timer
any of them provides possibility to define the number of requests per second, especially the latter one which can be connected with Concurrency Thread Group
I ran a jmeter test case where I found :-
Samples - 26133
99% Line to be - 2061ms
ThroughPut - 43.6/s
My question is how can the throughput be 43.6 requests per second when then 99% Line is showing at 2061ms. From my understanding that means 99% of the samples took NO MORE THAN this time. The 1% remaining samples took at least as long as this.
So Shouldn't the throughput be less than 1 request per second? How is it able to serve 46 requests per second when 99% itself take 2 seconds to respond?
99% is response time
Throughput is the number of requests for the test duration
Given the number of samplers and the throughput my expectation is that you ran your test for 10 minutes.
If you would execute your test with 1 user having response time of 2 seconds for 10 minutes you would get 300 samples. Looking at the numbers I can assume that you had something like 87 users.
And this 87 users (or whatever is your number) is a key point because throughput indicates concurrency
1 user which executes 1 request each 2 seconds - throughput will be 0.5 hits per second
2 users which execute 1 request each 2 seconds - throughput will be 1 hit per second
4 users which execute 1 request each 2 seconds - throughput will be 2 hits per second
etc.
More information:
JMeter Glossary
What is the Relationship Between Users and Hits Per Second?
I was told to use crontab expression to make my schedule trigger run every 3 minutes, however, I notice that it's not actually running every 5 minutes, what its doing is it runs a process for a period of 3 minutes and then it stops even if the process is not complete.
I need the trigger to run every 3 minutes but if its in the middle of a process then to complete the current process. Can you advise, please?
I noticed in the schedule trigger you have “start instance” and “stop instance”, currently they are both false. My guess is I need to do something with these?
The triggers never interrupt the script execution.
The special variable timeout is what will solve your problem. According to the manual the timeout special variable:
Defines the maximal robot process duration time (in milliseconds), after which the process terminates; the default value is 180000 (3 minutes).
Which means that a script will stop after 3 minutes if its timeout's variable value stays default.
Add the below line of code at the beginning of your script to prevent this from happening after 3 minutes and increase its maximal robot process duration time.
♥timeout = 1800000
By the way if you have set up your triggers to launch a script every 3 minutes and the script's duration time is for example 4 minutes, the script will be launched the next time automatically after because it is 1 minute late and it creates a queue of scripts to be executed.
I am new to Jmeter I don't have any idea about it. I want to use a Jmeter plugin named as Custom Thread Group -> Arrivals Thread Group available at location https://jmeter-plugins.org/wiki/ArrivalsThreadGroup/ for arrival rate simulation. I searched a lot about these properties but didn't get clear definition or understanding. I have a vague idea about its configuration properties. I wrote the details I know about all these properties as a code comment
Target Rate(arrivals/min): 60
Ramp Up Time(min): 1 // how long to take to "ramp-up" to the full number of threads
Ramp-Up Steps Count: 10 // It divides Ramp-up time into specified parts and ramp-up threads accordingly
Hold Target Rate Time(min): 2// It will repeat the same for the next two minutes
Thread Iterations Limit:
Can anybody help me to understand clearly what is the significance of all these properties?
According to above settings:
Target Rate: 60 arrivals in a minute means there will be one arrival per second. Each second JMeter will kick off a virtual user which will be executing samplers.
Ramp-up time: the time which will be taken to reach the target rate, i.e. JMeter starts from zero arrivals per minute and increases the arrivals rate to 60 arrivals per minute in 60 seconds.
Ramp-up steps: here you can set the “granularity” of increasing arrivals rate, more steps - more smooth pattern, fewer steps - you will have “spikes”
Hold Target Rate: it will keep the threads in steady state for the duration specified. In your case, it will keep a number of threads 60 for the end of the run. As explained in above comment.
So according to settings, JMeter will ramp-up from 0 to 1 arrival per second in one minute plus run the test for 2 minutes.
If I have 1 sampler in Test Plan it will be something like 153 executions, if I have 2 samplers - 153 executions per sampler, in total 306 executions. Approximate request rate will be 50 requests/minute.
If you have round robin enabled in Vxworks and your task gets preempted by a higher priority task, what happens to the remaining time slice?
Your task will resume execution and finish the remainder of the time slice.
Note that you will have some jitter that occurs for one time tick, since time slicing has a granularity of 1 clock tick.
For example:
You have round robin enabled with a 10 clock tick time slice. One clock tick is 10 ms. You expect 100 ms per time slice.
You get pre-empted at 5 ms (the middle of your 1st tick). You should run for 95ms more, but VxWorks considers that you still have 10 ticks to go.
If the task gets the cpu back at 11ms, you will execute 99ms more.
If the task gets the cpu back at 19ms, you will execute 91ms more.
Every time you get pre-empted, your task might execute +/- 1 tick in absolute time.