In Oracle AWR report i see mention of three terms i.e. DB time , Elapses Time , CPU time but i am not sure what does they actually mean
Say i have got the AWR report for 15 mins i.e 900 seconds. There are two cores. Statement1 took 20 seconds to actually parse sql, executing sql etc and 10 seconds is wait time
for other transaction to complete.
I believe DB time will be 900 secs. What will be be CPU and Elapsed time based on above use case ?
"CPU time" meaning that your statement was used CPU for N seconds
"Elapsed Time" mean all time for your statement, because you can spent it for waiting your HDD or locks or something else. It's all should be in AWR report if you tracing with maximum level
Elapsed Time - When looking into AWR report, the Elapsed Time is the wall clock time of duration for which AWR report has been generated. For example, if we generate AWR report for 1 hour then Elapsed Time in AWR report will be 60 mins.
DB CPU - DB CPU is the CPU consumption by all Oracle server processes/foreground processes during snapshot interval time.
DB Time - DB time is a statistic which represents CPU time consumed by all Oracle processes over a period of time plus non-idle wait time. DB Time is the time spent by the database server executing user calls. DB Time is the total time spent by the all user processes which are actively working or actively waiting in the database calls. It includes the CPU Time, IO Wait time and non-idle time. It tells us that how much activity performed by the database for the duration.
CPU is time spent on CPU.
DB Time is time spent by foreground sessions actively waiting or actively working.
Consider you have a 10 minute AWR interval and system has 4 CPUs.
The maximum CPU time available in that 10 minute period is 40 minutes.
also say that in that 10 minute period you have 3 sessions which have no idle time and are working or waiting for 100% of that 10 minute period.
The DB Time would be 30 minutes. (10*3) as all session either working or waiting during that 10 min
If you had four sessions actively working or actively waiting 100% of the time in that 10 minute period, then your DB time would be 40 minutes.
If you massively ramp up your activity and there were 100 session working/waiting for 10 minute period, DB time would be 1000 minutes.(10*100)
Related
I need to test an application can handle 500 users over the space on 1 hour. How long should I set the ramp up period for the specified amount of time and users?
It depends on what you're trying to achieve. There are no "strict" rules, no recommendations either.
As per JMeter documentation:
The ramp-up period tells JMeter how long to take to "ramp-up" to the full number of threads chosen. If 10 threads are used, and the ramp-up period is 100 seconds, then JMeter will take 100 seconds to get all 10 threads up and running. Each thread will start 10 (100/10) seconds after the previous thread was begun. If there are 30 threads and a ramp-up period of 120 seconds, then each successive thread will be delayed by 4 seconds.
Ramp-up needs to be long enough to avoid too large a work-load at the start of a test, and short enough that the last threads start running before the first ones finish (unless one wants that to happen).
Start with Ramp-up = number of threads and adjust up or down as needed.
So you can use 500 as ramp-up so all 500 users will be online in 500 seconds.
Other option is to set ramp-up period for 1st 30 minutes and next 30 minutes keep the load of 500 users.
The idea is to add users gradually so you could correlate increasing load with other metrics and KPIs like response time, number of transactions per second, number of errors, etc. so you could state where is the saturation point, where is the first bottleneck, etc.
More information: JMeter Ramp-Up Period: The Ultimate Guide
The ramp-up period, Is the time needed to start all the threads defined.
So, If you add 3600 with 500 Thread, This will mean a new thread will be launched every 7.2 seoconds, And the last one will start after 1h ( 3600 seconds)
If this is what you want, you can set Ramp up to 3600.
quote from official doc
The ramp-up period tells JMeter how long to take to "ramp-up" to the full number of threads chosen. If 10 threads are used, and the ramp-up period is 100 seconds, then JMeter will take 100 seconds to get all 10 threads up and running. Each thread will start 10 (100/10) seconds after the previous thread was begun.
How to calculate inputs (virtual users, ram up period) for performance and load testing using Jmeter.
If you're doing Load testing - you are supposed to be checking your system behaviour against the anticipated load, it means that you should know the expected number of users from NFR or SLA
If you don't have any requirements - go for the stress testing, i.e. start with 1 user and gradually increase the load until response time starts increasing or errors start occurring (whatever comes the first)
With regards to the ramp-up period duration - there are no strict requirements, as per JMeter Documentation
The ramp-up period tells JMeter how long to take to "ramp-up" to the full number of threads chosen. If 10 threads are used, and the ramp-up period is 100 seconds, then JMeter will take 100 seconds to get all 10 threads up and running. Each thread will start 10 (100/10) seconds after the previous thread was begun. If there are 30 threads and a ramp-up period of 120 seconds, then each successive thread will be delayed by 4 seconds.
Ramp-up needs to be long enough to avoid too large a work-load at the start of a test, and short enough that the last threads start running before the first ones finish (unless one wants that to happen).
Start with Ramp-up = number of threads and adjust up or down as needed.
so if you don't have any better ideas - just go for the above recommendation.
I have a requirement like API should be capable of handle 5k Concurrent user in 5 Sec.
How can i test this scenario in jmeter.
For 1k Concurrent user what should the RampUp time to be set in Jmeter.
5000 for 5 seconds is quite easy to achieve:
With normal Thread Group
With Concurrency Thread Group
With regards to the ramp-up, I can only give you:
a quote from JMeter documentation:
The ramp-up period tells JMeter how long to take to "ramp-up" to the full number of threads chosen. If 10 threads are used, and the ramp-up period is 100 seconds, then JMeter will take 100 seconds to get all 10 threads up and running. Each thread will start 10 (100/10) seconds after the previous thread was begun. If there are 30 threads and a ramp-up period of 120 seconds, then each successive thread will be delayed by 4 seconds.
Ramp-up needs to be long enough to avoid too large a work-load at the start of a test, and short enough that the last threads start running before the first ones finish (unless one wants that to happen).
Start with Ramp-up = number of threads and adjust up or down as needed.
and a piece of advice on ramp-up in general: if you're doing some form of a stress test it's a good idea to increase the load gradually, this way you will be able to correlate increasing load with the throughput and response time because running 5000 threads for 5 seconds will give you only a basic information on the response time for this workload and you won't be able to tell what is the maximum number of users/requests per second the application can support, when performance starts degrading, etc. So you could consider a load pattern like this:
and look at Response Times Over Time chart to see the relationship between the number of concurrent users and the application response time
In the Client Statistics Window in Sql Server Management Studio, I get the total
execution time.
However, this time is often muss less then the time the query actually took.
So what is the additional time spend for?
For example, here I got ~5,6 seconds of total execution time, but my query took 13 seconds to finish
The total execution time is the time until the result is available for display. But then, depending on the result set size and the way you display the data, the time until everything has been rendered is usually much higher.
I know that Little's Law states (paraphrased):
the average number of things in a system is the product of the average rate at which things leave the system and the average time each one spends in the system,
or:
n=x*(r+z);
x-throughput
r-response time
z-think time
r+z - average response time
now i have question about a problem from programming pearls:
Suppose that system makes 100 disk accesses to process a transaction (although some systems require fewer, some systems will require several hundred disk access per transaction). How many transactions per hour per disk can the system handle?
Assumption: disk access takes 20 milliseconds.
Here is solution on this problem
Ignoring slowdown due to queuing, 20 milliseconds (of the seek time) per disk operation gives 2 seconds per transaction or 1800 transactions per hour
i am confused because i did not understand solution of this problem
please help
It will be more intuitive if you forget about that formula and think that the rate at which you can do something is inversely proportional to the time that it takes you to do it. For example, if it takes you 0.5 hour to eat a pizza, you eat pizzas at a rate of 2 pizzas per hour because 1/0.5 = 2.
In this case the rate is the number of transactions per time and the time is how long a transaction takes. According to the problem, a transaction takes 100 disk accesses, and each disk access takes 20 ms. Therefore each transaction takes 2 seconds total. The rate is then 1/2 = 0.5 transactions per second.
Now, more formally:
Rate of transactions per seconds R is inversely proportional to the transaction time in seconds TT.
R = 1/TT
The transaction time TT in this case is:
TT = disk access time * number of disk accesses per transaction =
20 milliseconds * 100 = 2000 milliseconds = 2 seconds
R = 1/2 transactions per second
= 3600/2 transactions per hour
= 1800 transactions per hour