No of Virtual Machine(s)
Virtual machines are child processes that are created by LOAD TEST parent process to distribute the load (users/sessions) among them. There are two fields first one for count and second one to select either Machine or CPU.
CPU User can specify the maximum number of virtual machines per CPU with specified max limit.
Example: If user choose 4 NVM per CPU upto 64 on a server which has 8 core cpu then it can generate load from maximum 32 virtual machines. but if user choose 8 NVM per CPU upto 64 then it can generate load from maximum 64 virtual machines as per the max limit.
Note : User can also specify Min Session Rate/Users per Virtual Machine field to maximum utilization of Virtual machines
Machine User can specify the maximum Number of virtual machines.
Copy Script in test run
When enabled, all the scripts are copied in the Testrun. When "Exclude Dump" option is enabled, dump files are skipped while copying the script in test run.
Optimize Ethernet packet flow
User can optimize the Ethernet packet flow by using the following options (By default, 10 packets are exchanged between client and server):
Handshake Merge Ack It reduces 1 packet, 9 packets are exchanged between client and server (packets 3 and 4 are merged into a single packet).
Data Merge Ack It reduces 1 packet, 9 packets are exchanged between client and server (packets 7 and 8 are merged into a single packet).
Close by Reset It reduces 2 packets, 8 packets are exchanged between client and server (packets 8, 9, and 10 are merged into a single packet).
User/Session distribution (%) over NVMs
It contains following options:
Distribution for maximum performance. A test group may be distributed over 1 or more NVMs : All Users/Sessions is distributed over 1 or more NVMs as per the setting in Number of virtual Machine.
Distribution for maximum isolation among scripts. All test groups using the same script is executed only by one NVM : Users/Sessions of the same script is assigned to one NVM (Number of Virtual machines= different number of scripts used in test file).
User specifies NVM Id for each test group : Users/Sessions of same cluster id is assigned to one NVM (Number of Virtual Machines = different number of cluster IDs).
Virtual User Thread Pool
It is a collection of Virtual users where each VUser is considered a thread. It is used for ramping up/ramping down users as specified in the test when the script is run in thread mode. The user needs to provide the following inputs
Initial number of threads Initial number of threads to be used in the test.
Increment By How many threads are to be increased when the initial gets exhausted.
Max Maximum number of threads to be used for a test.
Thread stack size Stack of each thread in KBs.
Maximum number of dynamic hosts
Maximum number of different hosts allowed to connect.
Maximum Number of Concurrent Sessions
It defines the number of concurrent sessions that need to be executed. Only a defined number of sessions runs parallel, the rest are in a Blocked state.
Test on Generator failures
Stop test on Controller if one (or more) of the following thresholds are breached. It will stop the test on the controller as per the threshold.
Stop test on Generator if one (or more) of the following thresholds are breached. It will stop the test on the Generator as per the threshold.
TCP Connection Port Selection Settings
Socket Binding is the process of allocating a Port number to a Socket to address a network within a system.
Mode for Port Selection Selection of the Port is either 'Sequential' or 'Random' mode. By default, it is Sequential Mode.
Number of retries on socket Bind Failure Number of retries to be attempted once bind failed on the socket. After retry attempt exhaustion, the provided action is implemented.
Action to be taken on failure When retry attempts are exhausted, action is taken according to the option applied. Options can be 'Enable' or 'Disable'.
Capture TCP dump for controller/generators Communication Troubleshooting
This option is used to capture the TCP dump on generator (s) or controller accordingly. You can capture the TCP dump with any of the following two options:
1. Capture TCP Dump on Generator
2. Capture TCP Dump on Controller
Capture TCP Dump on Generator : TCP dump on generator is taken on connection failure or progress report delay. The TCP dump is taken in two cases:
1.
On Start of Test, generator make a connection to controller. If the connection fails, it retires on every 1 second for 5 times. The TCP dump is started on the first connection failure.
2.
The generator sends progress reports to controller for every progress interval. Progress reports has sample number 1 to N. Controllers sends acknowledgement for progress reports with sample number of the progress report received. If difference of generator current sample number and controller acknowledgement sample number is more than 1/2 of the progress report queue size, it is indication of either progress reports are not reaching controller on time or are not sent by generators. TCP dump is taken in this case to see if data is going on the connection or not.
Capture TCP Dump on Controller : TCP dump on controller is taken on progress report delay. TCP dump is taken when difference of progress report sample number of the generator and maximum sample number received from all generators is more than 1/2 of the progress report queue size. For example, if maximum sample number is 11 and sample number received from generator1 is 5, then TCP dump will be taken for generator1.
Max Concurrent TCP Dump : It is the maximum concurrently TCP dump taken on generators.
TCP Dump Duration : TCP dump will be captured for a given duration in Seconds.
TCP Dumps are stored in the test run directory with filename:
${NS_WDIR}/logs/TR${TEST_RUN}/ns_logs/tcpdump/tcpdump.mmddyyyyhhmmss.pcap
Generator TCP dump is stored in
$NS_WDIR/logs/TR${TEST_RUN}/server_logs/date/GenName_tcpdump.mmddyyyyhhmmss.pcap
Netstat output is stored in
${NS_WDIR}/logs/TR${TEST_RUN}/NetCloud/${GEN_NAME}/${GEN_TEST_RUN}/netstat_output.txt"
IO Vector
It is the configuration setting of the IO vector used by LOAD TEST for sending requests on socket.
Initial Vector Size : Initial number of allocated IO vectors. Cannot be less than 100
Increment By : Increment size for reallocating IO vectors. Should be greater than 0 and less than max.
Maximum Size : Maximum number of IO vectors that can be allocated for the whole test.
Whitelist Http Header
In Load Test, load generator is generating huge traffic on applications and most applications have rate limits. They will rate the limit and restrict the IP address from the load generator to stop any malicious or unauthorised attacks. We either apply whitelist IP or header to get around this restriction. We can provide whitelist headers in the request to allow load generation from a generator. These headers can be user agent or other according to application.
Send Whitelist Header in the Request : In send whitelist HTTP header, you have to provide the header name which you want to send with the request. You can send the header value or the IP address or can send the combination of both for whitelisting.
Note : For whitelisting, the most commonly used header is User-Agent, but you can also use any other headers. This header is also passed on the script, so it will duplicate this header. If you want to remove duplicacy then you have to remove this header from the script and check User-Agent from the given path:
Group Based Settings-> Developer Options-> HTTP(s)-> SEND FOLLOWING HEADERS WITH HTTP REQUESTS FROM SCRIPT.
Override Dashboard Default Favorite
By selecting this option, you can change the default favorite option. The selected favorite will be applied in all the test runs generated using this test. This option will override the default favorite configured in the Organized Favorite Window.
Ports for Generator to Controller Communication
In some cases, where firewall is present between generators and controller which can give error in making connection from generator to controller. So, we need to enable the firewall for the port range. The default range is set to 7914 to 7920.
When none of the ports from the above range is available then user can also select the checkbox to use system assigned port. If user don't select this checkbox then test will stop.
Note At least 3 ports are needed in the port range.