The main idea of this article is to acquaint the reader with the basic terms of load testing. The article does not purport to be complete descriptions of the entire process of load testing, but will help you to start in this interesting case.
• Script - recorded actions of a real user, which we can play back.
• Load Generator - Machine + program that can execute this script and simulate the actions of many users.
• Controller - machine + software that controls the start, stop of users on other machines and get them to report.
• Monitor - part of the controller, which makes monitoring of the system under test (under load), i.e., produces readout. In the ideology it is no need to install LoadRunner on the machine under test additional software that will remove indicators (and influence the test results!).
• Commanding from the machine of controller we run a script of virtual user in parallel many times from different machines.
• We collect data of the work on the machine that leads the process.
Vuser is a virtual user, the script which emulates the actions of one particular user. It is able to do what we had taught it during the recording, parameterization, and other patient preparation.
For example: it logins, causes the action against the server, receives the result (wait for it or not) and logs out. From the perspective of the whole system of software testing it is a party that receives the scenario where to go and what to do at the start, receives instructions from the controller about the run of other v-users (crowd, or more nimble escape forward), listened attentively to what he need to do if somewhere it is impossible to run and where he has to report.
Then after the whistle of controller he runs around the well-known scenario (sequence of actions) and “calls back” for about the outcome of the race. From a technical standpoint, each user can be a single instance of software-engine, which performs the script of the user (so is faster, but also the resources to it).
That means that scripts are executed in multimedia mode (in the documentation there is a reservation that the system must support such a mode of program) and perhaps may be one of the processes of the program-engine, then it will share memory with others v-users which steers by engine. It requires more memory and speed is lower.
Multithreading is not supported for all protocols! But if it is available it is recommended to use it rather than processes. It is precisely because the consumption of resources of load generator machine (mainly memory) while significantly smaller, which allows to run a lot of Vusers in a single load generator.
Vugen is generator of v-users, so smart tool, which sits between the client, who pulls the application / server and the application itself or server, which is under test. During the user experience, Vugen catch all the API calls that the user throws to the server and all responses of the server.
Scenario is a list of V-users (with names and surnames), which is defined how many V-users we will get to run, from what machines, and some scripts we'll get them to do.
Controller - machine, which is the command to start / stop control / coordination (Rendezvous - what a beautiful French word) of V-users on the machines, with which our v-users teasing the system under test. The same controller collects the data / reports from users to build then the beautiful graphics or reports that we have something to fall. This may be a machine of the tester. Data on work of v-users are robbed on this machine (how long have they worked, what are they doing now, etc.)
Beautiful graphics is not built by controller, but by a third module LoadRunner, called Analysis. It gets the input file with the results of running the script (.(.lrr -file) and creates an analysis session. This session could be maintained if there is a need (.(.lrr -file).
Load generator (load injector) is a real car, on which an engine stands that can run scripts of v-users. It subjects to the controller, listening to their complaints and gave reports to the controller.