Transaction per second - vuser relation - performance-testing

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

Related

Am I applying Little's Law correctly to model a workload for a website?

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

Azure logic app twitter trigger not working

I have created a logic app to trigger when a tweet is posted with a given hashtag. The trigger is set to check every 10 seconds. The reality is that the Logic App does not run, even if I wait minutes for it, but then if i manually run it, it then executes with the expected input. Any idea what is happening here?
I was having a similar issue, and believe this is due to the specific limitations set for the Twitter Connector (4. Frequency of trigger polls: 1 hour).
https://learn.microsoft.com/en-us/connectors/twitterconnector/
LIMITS
The following are some of the limits and restrictions:
Maximum number of connections per user: 2
API call rate limit for POST operation: 12 per hour
API call rate limit for other operations: 600 per hour
Frequency of trigger polls: 1 hour
Maximum size of image upload: 5 MB
Maximum size of video upload: 15 MB
Maximum number of search results: 100
Maximum number of new tweets tracked within one polling interval: 5
There should be some error occurred. You can inspect all runs of the triggers on the 'Trigger History' blade. This page gives a good overview of monitoring of logic apps: https://azure.microsoft.com/en-us/documentation/articles/app-service-logic-monitor-your-logic-apps/

How to calculate the number of seconds when a TOTP will expire in?

I am generating a simple token in my node app using notp:
var notp = require('notp')
notp.totp.gen("ciao", {}) // => 345678
I want to build a visualization similar to the one that Google Authenticator gives, and I need to know the number of seconds (or datetime) when the generated otp will expire.
How can I do it?
I've found it how to do it, it is actually pretty simple, you just need to know the time of start used by the algorithm.
It turns out that Google Authenticator uses Unix Epoch, so in my case, to display the timer I can do:
setInterval(() => (console.log(30 - Math.round(new Date() / 1000) % 30)), 1000)
This should be very simple,
The code within Google Authenticator App and on the server will then refresh with a new code every 30 seconds starting at the top of the minute.
Proof here: https://github.com/google/google-authenticator/blob/bd50d15c348a978c314d2b30e586fbc562096223/mobile/blackberry/src/com/google/authenticator/blackberry/AuthenticatorScreen.java#L53
So as long as you have your server and Apps synced these 30 second intervals will always be the same as they always start at the start of the minute and at 1 min and 30 seconds.
Another factor to take into account is that Google Authenticator on the server side can be setup to allow codes to be valid for only 30 seconds OR for 4 minutes. So you need to check if your server is setup at 30 seconds OR 4 minutes and then code accordingly.
Example of this when you setup:
By default, tokens are good for 30 seconds and in order to compensate
for possible time-skew between the client and the server, we allow an
extra token before and after the current time. If you experience
problems with poor time synchronization, you can increase the window
from its default size of 1:30min to about 4min. Do you want to do so
(y/n)

How to calculate number of users and think time for load testing

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.

Performance testing - Jmeter results

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.

Resources