JENKINS Time based Scheduling the Test run

# Starting nightly builds for regression testing in continous integration.

Step1:
Add a new Jenkins job.
select : Freestyle project.

Step2:
In "build Triggers"
select checkbox : Build Periodically.
enter the following : 15 13 * * *

this will auto schedule the jenkins job to start the build every day of every month of every year at the 15th minute of the 13th hour of the day.

The Jenkins used is a cron expression, the different fields are :

MINUTES Minutes in one hour (0-59)
HOURS Hours in one day (0-23)
DAYMONTH Day in a month (1-31)
MONTH Month in a year (1-12)
DAYWEEK Day of the week (0-7) where 0 and 7 are sunday

If you want to schedule your build every 5 minutes, this will do the job : */5 * * * *

If you want to schedule your build every day at 8h00, this will do the job : 0 8 * * *

Jenkins lets you set up multiple times, separated by line breaks.
If you need it to build daily at 7am, along with every Sunday at 4pm, the below works well

H 7 * * *
H 16 * * 0


step3:
In build: select "execute windows batch command"
add the path to the batch file like :

C:\Users\Administrator\Desktop\testbatchfile\MQTT_ENERGY.bat

step4:
save.

-------------------------------
#Two ways to Set the duration of the test  :
1a. by adding the "scheduler" in the Thread group.
1b. And adding the value in the user.properties
duration=3600
'OR'
2. the test duration value can be provided in realtime at time of test execution via cmd. this value then overwrites the user.properties duration property.
-------------------------------

Achieving targetted Requests per minute.

Achieving desired Requests per minute

If the Jmeter test is not able to send the expected Number of requests per minute then the following could the reasons:

REASONS WHY LESS REQUETS PER MINUTE ARE SENT VIA TEST
1. Number of request per minute will be lower if the server is not capable of handling it.
2. There's also going to be problems, especially with latency - even if you could send exactly 6 per second, they're going to be sent sequentially (that's just how packets get sent) and may not all hit in that second, plus processing time.
3. API-buffer overflow: Generally when performance metrics specific x per second, it is measured over a period of time. Your API may even have a buffer - so you could technically send 6 per second, but process 5 per second, with a buffer of 20, meaning it'd be fine for 20 seconds of traffic, as you'd have sent 120, which would take 120/5 = 24 seconds to process. But any more than that would overflow the buffer. Therefore, to just send exactly 6 in a second to test is insufficient.

CHECKS:
1. Check the JVM size in jmeter test.
Set HEAP=-Xms2560m -Xmx5120m

2. Run incremental Load like 50, 60, 80,100,110 monitor the JVM and decide how many injectors (separate jmeter instances) are required. Based on that split the load into multiple injectors and run simultaneously.

3. Try with Constant throughtput timer – to add a value for the RPM-requests per minute that are expected for a certain scenario.

set duration of automated load tests

${__property(duration,,)}