Gatling: Understanding rampUsersPerSec(minTPS) to maxTPS during seconds - scala

I am checking a scala code for gatling where they inject transactions for the period of 20 seconds.
/*TPS = Transaction Per Second */
val minTps = Integer.parseInt(System.getProperty("minTps", "1"))
val maxTps = Integer.parseInt(System.getProperty("maxTps", "5"))
var rampUsersDurationInMinutes =Integer.parseInt(System.getProperty("rampUsersDurationInMinutes", "20"))
setUp(scn.inject(
rampUsersPerSec(minTps) to maxTps during (rampUsersDurationInMinutes seconds)).protocols(tcilProtocol))
The same question was asked What does rampUsersPerSec function really do? but never answered. I think that ideally the the graph should be looking like that.
could you please confirm if I correctly understood
rampUsersPerSec?
block (ramp) 1 = 4 users +1
block (ramp) 2 = 12 users +2
block (ramp) 3 = 24 users +3
block (ramp) 4 = 40 users +4
block (ramp) 5 = 60 users +5
The results show that the requests count is indeed 60. Is my calculation correct?
---- Global Information --------------------------------------------------------
> request count 60 (OK=38 KO=22 )
> min response time 2569 (OK=2569 KO=60080 )
> max response time 61980 (OK=61980 KO=61770 )
> mean response time 42888 (OK=32411 KO=60985 )
> std deviation 20365 (OK=18850 KO=505 )
> response time 50th percentile 51666 (OK=32143 KO=61026 )
> response time 75th percentile 60903 (OK=48508 KO=61371 )
> response time 95th percentile 61775 (OK=61886 KO=61725 )
> response time 99th percentile 61974 (OK=61976 KO=61762 )
> mean requests/sec 0.741 (OK=0.469 KO=0.272 )
---- Response Time Distribution ------------------------------------------------

rampUsersPerSec is an open workload model injection where you specify the rate at which users start the scenario. The gatling documentation says that this injection profile
Injects users from starting rate to target rate, defined in users per second, during a given duration. Users will be injected at regular intervals
So while I'm not sure that the example you provide is precisely correct in that gatling is using a second as the 'regular interval' (it might be a smoother model), you are more or less correct. You specify a starting rate and a final rate, and gatling works out all the intermediate injection rates for your duration.
Note that this says nothing about the number of concurrent users your simulation will generate - that is a function of the arrival rate (which you control) and the execution time (which you do not)

Related

FleetApi - How to use legal rest times?

I'd like to know the position in which the driver would need to rest with given waypoints.
I am calling GET https://fleet.ls.hereapi.com/2/calculateroute.json with the following params:
{
mode: "fastest;car;traffic:enabled",
waypoint0: "19.286769, -99.652773",
waypoint1: "19.419185, -99.17755430000001",
waypoint2: "19.41530,-99.17844",
waypoint3: "31.29778, -110.93690",
restTimes: "MEX",
maxSpeed: 110,
departure: "2021-07-20T15:00:00.000Z"
}
This returns warnings with the info of rest times like this:
{
"message": "Taking the short driver rest time after 18036 sec for 1800 sec at routeLinkSeqNum 1485",
"code": 14,
"routeLinkSeqNum": 1485
}
I would like to know how to use/read this info. I don't know what routeLinkSeqNum is and how to utilize it.
Governments impose rules on how long a truck driver can drive before he needs to rest. Routing can consider these regulations w.r.t. short rests during a day and long (overnight) rests.
For example, in EU countries drivers have to rest after 4.5 hours of driving for at least 45 minutes, and must not exceed a total of 9 working hours per day before they have to rest for 11 hours.
Activate this feature in the router using the "&restTimes=local", in this case, it is the "MEX" in the request parameter. Routing will then consider each country's local regulations.
In the same parameter, you can specify whether the driver starts the route freshly or how long he is already driving / on duty since his last short or long rest period
routeLinkSeqNum is an index of the link array within a Leg. If you check the response, there will be response>route>[0]>leg[0]>[2]>link[1485].
So one route can have n-legs, 1 leg can have m-links
This will help you to plot the rest times.
Here is an example shown in the tool:
https://tcs.ext.here.com/examples/v3/fleet_telematics_api

How to exclude spikes from SumoLogic alert?

We have SumoLogic alert that happens if more than 10 errors logged in 60 min.
I prefer to have something like: 
if there is a spike and all the errors happen in e.g. 1 minute ( consider as issue has been auto resolved ) do not generate alert.
How can I set such sumoLogic query?
Variances of the requirements :
Logs have clientIp field, and if all errors are reported for the same client, do not generate alert( problem with particular client, not with application)
if more than 10 errors logged in 60 min, send an alert, unless the errors are of type A, but if there are more than 100 errors of type A, send the alert.( log errors of type A are acceptable, unless the number is too big)
if more than 10 errors logged in 60 min, send an alert Only if the last error happened less than 30 min ago(otherwise consider as auto-fixed)
I am not fully sure how is your data shaped, but...
if there is a spike and all the errors happen in e.g. 1 minute ( consider as issue has been auto resolved ) do not generate alert.
This you can solve by aggregating:
| timeslice 1m
| count by _timeslice
| where _count > 1
or similar.
if all errors are reported for the same client, do not generate alert
It sounds like:
| count by _timeslice, clientIp
would do the job.
if more than 10 errors logged in 60 min, send an alert, unless the errors are of type A, but if there are more than 100 errors of type A,
Rough sketch of the query clause would be:
| if(something, 1, 0) as is_of_type_A
| count by is_of_type_A, ...
| where (is_of_type_A = 1 and _count > 100)
OR (is_of_type_A = 0 and _count > 10)
Disclaimer: I am currently employed by Sumo Logic.

Gatling load testing and running scenarios

I am looking to create three scenarios:
The first scenario will run a bunch of GET requests for 30s
The second and third scenarios will run in parallel and wait until the first is finished.
I want the requests from the first scenario to be excluded from the report.
I have the basic outline of what I want to achieve but not seeing expected results:
val myFeeder = csv("somefile.csv")
val scenario1 = scenario("Get stuff")
.feed(myFeeder)
.during(30 seconds) {
exec(
http("getStuff(${csv_colName})").get("/someEndpoint/${csv_colName}")
)
}
val scenario2 = ...
val scenario3 = ...
setUp(
scenario1.inject(
constantUsersPerSec(20) during (30 seconds)
).protocols(firstProtocaol),
scenario2.inject(
nothingFor(30 seconds), //wait 30s
...
).protocols(secondProt)
scenario3.inject(
nothingFor(30 seconds), //wait 30s
...
).protocols(thirdProt)
)
I am seeing the first scenario being run throughout the entire test. It doesn't stop after the 30s?
For the first scenario I would like to cycle through the CSV file and perform a request for each line. Perhaps 5-10 requests per second, how do I achieve that?
I would also like it to stop after the 30s and then run the other two in parallel. Hence the nothingFor in last two scenarios above.
Also how do I exclude from report, is it possible?
You are likely not getting the expected results due to the combination of settings between your injection profile and your "Get Stuff" scenario.
constantUsersPerSec(20) during (30 seconds)
will start 20 users on scenario "Get Stuff" every second for 30 seconds. So even during the 30th second, 20 users will START "Get Stuff". The injection pofile only controls when a user starts, not how long they are active for. So when a user executes the "Get Stuff" scenario, they make the 'get' request repeatedly over the course of 30 seconds due to the .during loop.
So at the very least, you will have users executing "Get Stuff" for 60 seconds - well into the execution of your other scenarios. Depending on the execution time for you getStuff call, it may be even longer.
To avoid this, you could work out exactly how long you want the "Get Stuff" scenario to run, set that in the injection profile and have no looping in the scenario. Alternatively, you could just set your 'nothingFor' values to be >60s.
To exclude the Get Stuff calls from reports, you can add silencing to the protocol definition (assuming it's not shared with your other requests). More details at https://gatling.io/docs/3.2/http/http_protocol/#silencing

How to define step load on gatling

I'm a Performance QC engineer, so far i used Visual Studio Ultimate to run load test bug now I'm going to change to gatling. So I'm a newbie on gatling and scala.
I'm defining the simulation with step-load scenario here:
Initial: 5 user
Maximum user count: 100 users
Step duration: 10 seconds
Step user count: 5 users
Duration: 10 minutes
Meaning: start with 5 users > after 10 seconds increase 5 users: repeat until maximum 100 user and run the test in 10 minutes.
I tried some code and other injects but the result is not as expected:
splitUsers(100)
into(rampUsers(5)
over(10 seconds))
separatedBy(10 minutes)
Could you please help me to simulate the step load on gatling?
define the User injection part in setUp something like this
setUp(
scn.inject(
atOnceUsers(5), //Initial: 5 user
nothingFor(10 seconds), //A pause to uniform the step load
splitUsers(100) into atOnceUsers(5) separatedBy(10 seconds) //max user,split time,number of user
).protocols(httpConf))
the duration you can define just by using during function over scenario. Hope it helps
Can you be more specific about the result not being as expected?
According to the documentation your situation should be:
splitUsers(100) into(rampUsers(5) over(10 seconds)) separatedBy atOnceUsers(5)
If test duration is the target then have a look at Throttling in the Gatling documentation.

swfupload get timer left

is it any possible to get time left for uploading files using swfupload?
You can most certainly estimate the time remaining, but this isn't a feature built-in to SWFUpload to my knowledge. Here's what I do:
In your uploadStart() handler for your file, record the start time of the upload and store in somewhere.
var startTime = +new Date(); // the current date time in UTC * 1000 milliseconds
Then, in your uploadProgress() handler for the same file:
var percentage = bytesLoaded/file.size,
timeDiff = +new Date() - startTime,
status = (percentage > 0 ? Math.round(timeDiff / percentage / 1000 * (1 - percentage)) + " seconds remaining." : "Uploading...");
Works well!
I hope this is helpful.
EDIT, added test for percentage > 0
No, because the time taken to upload anything over a normal Internet connection can never be known in advance due to speed fluctuations. On the other hand swfupload provides a progress handler to report the percentage uploaded so you can either use that to display a progress counter/bar or guesstimate the time remaining based on the time already spent and hope it's somewhat accurate.