On a Load Test with Loadrunner controller, I have a script which make 1029 Transactions per Hour with 1 Virtual User,with 1 "number of Iteration" ,"ignore think time", and pacing setting which start every iteration at a random interval every 3 to 4 seconds but I want to reduce the transactions to 45 Transactions per Hour. I set then the think time to "Limit think time to : 65", but without success.
Does anyone knows how to reduce the number of transactions. Is there any run time setting which must be changed to get this transactions reduced?
Use 'fixed' intervals of 80 seconds.
45 transactions per hour
3600 seconds in an hour
= 80 seconds per transaction
Related
Using these metrics (shown below), I was able to utilize a workload modeling formula (Little’s Law) to come up with what I believe are the correct settings to sufficiently load test the application in question.
From Google Analytics:
Users: 2,159
Pageviews: 4,856
Avg. Session Duration: 0:02:44
Pages / Session: 2.21
Sessions: 2,199
The formula is N = Throughput * (Response Time + Think Time)
We calculated Throughput as 1.35 (4865 pageviews / 3600 (seconds in an hour))
We calculated (Response Time + Think Time) as 74.21 (164 seconds avg. session duration / 2.21 pages per session)
Using the formula, we calculate N as 100 (1.35 Throughput * 74.21 (Response Time + Think Time)).
Therefore, according to my calculations, we can simulate the load the server experienced on the peak day during the peak hour with 100 users going through the business processes at a pace of 75 seconds between iterations (think time ignored).
So, in order to determine how the system responds under a heavier than normal load, we can double (200 users) or triple (300 users) the value of N and record the average response time for each transaction.
Is this all correct?
When you do a direct observation of the logs for the site, blocked by session duration, what are the maximum number of IP addresses counted in each block?
Littles law tends to undercount sessions and their overhead in favor of transactional throughput. That's OK if you have instantaneous recovery on your session resources, but most sites are holding onto them for a period longer than 110% of the longest inter-request window for a user (the period from one request to the next).
Below formula always worked good for me, If you are looking to calculate pacing
"Pacing = No. of Users * Duration of Test (in seconds) / Transactions you want to achieve in said Test Duration"
You should be able to get closer to the Transactions you want to achieve using this Formula. If Its API, then its almost always accurate.
For Example, You want to achieve 1000 transactions using 5 users in one hour of Test Duration
Pacing = 5 * 3600/1000
= 18 seconds
I want to know how to calculate number of users, Think time, Pacing time and number of Iteration for load testing.
Requirement is:
I need to achieve 10000 transaction per hour.
Need to do 1 hour execution.
Need to specify think time and pacing time
Note:
My script "aircraft" contains 7 transactions.
Overall Response time is 16 sec without think time.
How to calculate how many users to be given so that I can achieve 10000 transaction per hour and how much think time and Pacing time and number of Iteration I need to specify?
If your only goal is to simulate a certain number of transactions in a certain time period, you can do that with quite few virtual users in the test.
If your average transaction time for 7 transactions is 16 seconds it means you can do 7/16 transactions per second, using a single virtual user.
To get 10,000 transactions in an hour you would have to use multiple concurrent virtual users.
VU = Number of virtual users
time = test time in seconds
TPS = transactions per second
VU * time * TPS = total_transactions
In this case we know total_transactions but not VU, so we rewrite it to:
total_transactions / (time * TPS) = VU
Using the numbers we have, we get:
10000 / (3600 * 7/16) = 6.3
I.e. you need more than 6 VUs to get 10k transactions in one hour. Maybe go for 10 VUs and insert some sleep time as necessary to hit the exact 10,000 transactions.
How much sleep time and how many iterations would you get then?
10 users executing at 7 transactions per 16 seconds for one hour would execute a total of 10 * 7/16 * 3600 = 15,750 transactions. We need to slow the users down a bit. We need to make sure they don't do the full 7/16 transactions per second. We can use the formula again:
VU * time * TPS = total_transactions
TPS = total_transactions / (VU *time)
TPS = 10000 / (10 * 3600) => TPS = 0.2777...
We need to make sure the VUs only do 0.28 TPS, rather than 7/16 (0.44) TPS.
TPS = transactions / time
Your script does 7 transactions in 16 seconds, to get 7/16 (0.44) TPS.
To find out how much time the script needs to take, we then change it to:
time = transactions / TPS
time = 7 / 0.277778 => time = 25.2 seconds
Currently, your script takes 16 seconds, but we need it to take 25 seconds, so you need to add 9 seconds of sleep time.
So:
10 VUs, executing 7 transactions in 25 seconds, over the course of an hour, would produce 10,000 transactions:
10 * 7/25 * 3600 = 10080
The number of script iterations each VU would perform would be:
3600 / 25 = 144 iterations
To sum up:
Number of VUs: 10
Total sleep time during one iteration: 9
Iterations/VU: 144
Note that this all assumes that transaction time is constant and does not increase as a result of generating the traffic. This setup will generate close to 3 transactions per second on the target system, and if you have not tested at that frequency before, you don't know if that will slow down the target system or not.
I have one question: you mentioned TPS:7/16 - on what basis it is 7/16? It's 16/7.
Otherwise, take this calculation: 10000 transactions per hour, then per sec 10000/3600 = 2.77; this and 7/16 are the same. I think your calculation is wrong. Please correct me.
I am using Jmeter (started using it a few days ago) as a tool to simulate a load of 30 threads using a csv data file that contains login credentials for 3 system users.
The objective I set out to achieve was to measure 30 users (threads) logging in and navigating to a page via the menu over a time span of 30 seconds.
I have set my thread group as:
Number of threads: 30
Ramp-up Perod: 30
Loop Count: 10
I ran the test successfully. Now I'd like to understand what the results mean and what is classed as good/bad measurements, and what can be suggested to improve the results. Below is a table of the results collated in the Summary report of Jmeter.
I have conducted research only to find blogs/sites telling me the same info as what is defined on the jmeter.apache.org site. One blog (Nicolas Vahlas) that I came across gave me some very useful information,but still hasn't help me understand what to do next with my results.
Can anyone help me understand these results and what I could do next following the execution of this test plan? Or point me in the right direction of an informative blog/site that will help me understand what to do next.
Many thanks.
According to me, Deviation is high.
You know your application better than all of us.
you should focus on, avg response time you got and max response frequency and value are acceptable to you and your users? This applies to throughput also.
It shows average response time is below 0.5 seconds and maximum response time is also below 1 second which are generally acceptable but that should be defined by you (Is it acceptable by your users). If answer is yes, try with more load to check scaling.
In you requirement it is mentioned that you need have 30 concurrent users performing different actions. The response time of your requests is less and you have ramp-up of 30 seconds. Can you please check total active threads during the test. I believe the time for which there will be 30 concurrent users in system is pretty short so the average response time that you are seeing seems to be misleading. I would suggest you run a test for some more time so that there will be 30 concurrent users in the system and that would be correct reading as per your requirements.
You can use Aggregate report instead of summary report. In performance testing
Throughput - Requests/Second
Response Time - 90th Percentile and
Target application resource utilization (CPU, Processor Queue Length and Memory)
can be used for analysis. Normally SLA for websites is 3 seconds but this requirement changes from application to application.
Your test results are good, considering if the users are actually logging into system/portal.
Samples: This means the no. of requests sent on a particular module.
Average: Average Response Time, for 300 samples.
Min: Min Response Time, among 300 samples (fastest among 300 samples).
Max: Max Response Time, among 300 samples (slowest among 300 samples).
Standard Deviation: A measure of the variation (for 300 samples).
Error: failure %age
Throughput: No. of request processed per second.
Hope this will help.
I want to setup loadtest with Loadrunner. System requirements are as below
1- max 30K users can be online i want to test if system can reach 15TPS.
2- i want to test if system can reach 2000TPS while some of online
users can visit 5 different pages. With how many vusers i should do this test ?
For both browsing and login operations response time is 0.1 or 0.2 seconds but think-time is ignored for login operation but 5 minutes for browsing operations. ( This value can be changed for sake of simplecity.) For login operation i setup vusers count to 30 and used 1000 iterations for reaching 15TPS.
i know that we can calculate vusers with below
number of required VUsers = required transaction per seconds * user
scenario length (sec)
but i m not sure how to apply this to second scenario.
Required TPS =15
users 5
Pacing =5/15
use this and it will work
We have a metric that we increment every time a user performs a certain action on our website, but the graphs don't seem to be accurate.
So going off this hunch, we invested the updates.log of carbon and discovered that the action had happened over 4 thousand times today(using grep and wc), but according the Integral result of the graph it returned only 220ish.
What could be the cause of this? Data is being reported to statsd using the statsd php library, and calling statsd::increment('metric'); and as stated above, the log confirms that 4,000+ updates to this key happened today.
We are using:
graphite 0.9.6 with statsD (etsy)
After some research through the documentation, and some conversations with others, I've found the problem - and the solution.
The way the whisper file format is designed, it expect you (or your application) to publish updates no faster than the minimum interval in your storage-schemas.conf file. This file is used to configure how much data retention you have at different time interval resolutions.
My storage-schemas.conf file was set with a minimum retention time of 1 minute. The default StatsD daemon (from etsy) is designed to update to carbon (the graphite daemon) every 10 seconds. The reason this is a problem is: over a 60 second period StatsD reports 6 times, each write overwrites the last one (in that 60 second interval, because you're updating faster than once per minute). This produces really weird results on your graph because the last 10 seconds in a minute could be completely dead and report a 0 for the activity during that period, which results in completely nuking all of the data you had written for that minute.
To fix this, I had to re-configure my storage-schemas.conf file to store data at a maximum resolution of 10 seconds, so every update from StatsD would be saved in the whisper database without being overwritten.
Etsy published the storage-schemas.conf configuration that they were using for their installation of carbon, which looks like this:
[stats]
priority = 110
pattern = ^stats\..*
retentions = 10:2160,60:10080,600:262974
This has a 10 second minimum retention time, and stores 6 hours worth of them. However, due to my next problem, I extended the retention periods significantly.
As I let this data collect for a few days, I noticed that it still looked off (and was under reporting). This was due to 2 problems.
StatsD (older versions) only reported an average number of events per second for each 10 second reporting period. This means, if you incremented a key 100 times in 1 second and 0 times for the next 9 seconds, at the end of the 10th second statsD would report 10 to graphite, instead of 100. (100/10 = 10). This failed to report the total number of events for a 10 second period (obviously).Newer versions of statsD fix this problem, as they introduced the stats_counts bucket, which logs the total # of events per metric for each 10 second period (so instead of reporting 10 in the previous example, it reports 100).After I upgraded StatsD, I noticed that the last 6 hours of data looked great, but as I looked beyond the last 6 hours - things looked weird, and the next reason is why:
As graphite stores data, it moves data from high precision retention to lower precision retention. This means, using the etsy storage-schemas.conf example, after 6 hours of 10 second precision, data was moved to 60 second (1 minute) precision. In order to move 6 data points from 10s to 60s precision, graphite does an average of the 6 data points. So it'd take the total value of the oldest 6 data points, and divide it by 6. This gives an average # of events per 10 seconds for that 60 second period (and not the total # of events, which is what we care about specifically).This is just how graphite is designed, and for some cases it might be useful, but in our case, it's not what we wanted. To "fix" this problem, I increased our 10 second precision retention time to 60 days. Beyond 60 days, I store the minutely and 10-minutely precisions, but they're essentially there for no reason, as that data isn't as useful to us.
I hope this helps someone, I know it annoyed me for a few days - and I know there isn't a huge community of people that are using this stack of software for this purpose, so it took a bit of research to really figure out what was going on and how to get a result that I wanted.
After posting my comment above I found Graphite 0.9.9 has a (new?) configuration file, storage-aggregation.conf, in which one can control the aggregation method per pattern. The available options are average, sum, min, max, and last.
http://readthedocs.org/docs/graphite/en/latest/config-carbon.html#storage-aggregation-conf