There are various performance testing tools in market and it's advisable for a tester to do a sort of comparison in-terms of the product functionality.
Under Load Runner you could see following options made available
- Run Vusers as process
- Run Vusers as a thread
So there could be questions as to whether RPT provides similar functionality or how would the virtual user execution gets handled in RPT.
What happens if you specify 100 virtual users in the RPT schedule. Say, you have 10 user groups each one has an unique script with it. So10 users per user group, totally 100.
Whether it is treated as thread such that 100 threads will be running in the application during load test Or 100 unique processes?
RPT does not require a thread per test not it does require a thread per virtual user. When an individual action is being executed one thread is used.
One example of an action is an HTTP request. One thread is required to open a connection, if necessary, and write the request. Reading the response from the server is non-blocking. When data is available one thread is required to read the data and perform any processing required. Another example of an action is Custom Code. During the execution of the Custom Code exec() method one thread is required.
If you want to increase the number of threads you need to create a location file and run your user group on that location. You will need to open the location file in the test navigator and go to the General Properties tab. On this tab you will want to set RPT_VMARGS on the left hand side and the -Dvariables on the right hand side. You will probably want a max thread count of the total user load depending on how long you are sleeping and how long your loop takes to execute.
RPT_VMARGS = -DrptThreadCount=30 -DrptMaxThreadCount=50
In general, For the HTTP protocol the RPT engine will create a thread as needed up to a maximum of 500 threads. The need to execute an action (eg request send or response) and unavailability of a free thread is what controls creation of additional threads.
Unless there is some specific problem it is highly recommended to let RPT control the creation and deletion of threads.
So, if you are looking it specifically from RPT perspective, then the agent starts execution with 10 worker threads
These 10 worker threads handle the actions performed by the virtual users. In case the Agent detects that 10 worker threads are not sufficient for the run, it will spawn more threads in runtime.The threads are shared by the VUs. So there is no 1-1 mapping between threads and virtual users.
However if you are interested to control the threads, then the following system properties can influence thread control. These apply to the execution engine (ie location or agent) so a general property for the location must be created to set these system properties. For each location you must create a property called RPT_VMARGS and set it accordingly.
The default values are
-DrptThreadCount=10 (Initial number of worker threads)
-DrptMaxThreadCount=500 (Maximum number of worker threads)
-DrptThreadKeepAlive=60000 (Time thread may be idle before being removed)