Performance testing is an essential section of any functional web testing. Including performance evaluations in the planning and development cycles it guarantees that the customer receives the application that corresponds to the required load, availability and scalability. Earlier determining the load level is necessary in order to have time to setup the system before it will be used by real users.
A few points must be discussed for performance testing: how many requests can be managed per unit time, and how many requests the system can manage at a time. This type of testing not only provides a full measuring of system response time. It is also focuses on regression to the server and web-application code, i.e. if the server's response from the server is equal to the expected result. Performance testing also helps to evaluate and compare solutions from different vendors.
Apache JMeter is a little bit more technical and complex for using and adjusting, but it remains popular with a lot of technical quality assurance engineers who prefer to download quickly and start using the open source solution on any platform. Its data storage and reporting tools are also good as a standard and it supports major languages and a web architecture. Check out the most popular functionalities below.
Mentioned above, Apache JMeter is the application for carrying out performance test of Web-applications. It is widespread in testing Web-applications. The server performance under simulated high load can be measured by this application. So one of the nice features is that Jmeter consents to implement FTP or HTTP requests and different user's scripts.
Apache JMeter is an integral part of the functional web testing. It is a tool for testing web-applications that are used in HTTP and FTP servers. It is an application based on JAVA and it can be extensible through the provided API. A common JMeter test assumes creating an iteration and thread group with various percentage quantity proportions of features. The iteration simulates consequent functional web testing requests to the server with a specified delay.
Thread group is developed for simulating a parallel load from several devices. A user interface is ensured with the help of JMeter. It also visualizes an API that lets user to run tests that are based on JMeter Java application. Before creating a load test suite in JMeter it is necessary to build the test plan, that includes the consequence of the actions that JMeter is up to perform. The elementary test plan typically includes such parts:
Thread group - it is the quantity of running threads and an increasing time period. Every thread simulates a real user and the increase period specifies necessary time to run all quantity of the threads. For instance with 10 threads and 5 seconds of ramp-up period it will take 0.5 seconds between the creation of each thread. The cycle counter defines the running time for certain thread. The planner lets you set the start and end of the execution time as well.
Samplers - requests that are sent to the FTP, HTTP or LDAP servers.
Listeners - intended for posting process request data. As an option, a data can be saved by user. It also can display the results by using a diagram. At this moment many configuration options are not provided and many options of the configuration, visualization or data processing modules can be added.
Parametrization - it is a process of reckoning some user input that can be used for several users or iterations. E.g. search scenario must be put down for performance test of a web search service. In order to create efficient performance test, we can't just run the script for 500 users. It is necessary to simulate 500 users that search for 500 various requests. So the parametrization is needed, wherein is CSV file that should contain 500 different requests. These requests are recorded in the CSV file. You can also make the search request using CSV file dynamically. This method can be used instead of the static search requests. The screenshot below shows the settings of importing CSV file.
If the performance of your PC does not allow to run multiple threads at the same time or network speed is too low it is presumable to run it on multiple machines (servers) by controlling from the single machine (client). When Jmeter was run distantly it is possible to copy test to computers with low performance and therefore simulate the bigger load on the tested Web service. Any quantity of remote JMeter instances (servers) can be controlled by one instance of the JMeter client and assemble all the data from these servers. It gives such possibilities:
Test samples are saved on the local machine;
Multiple JMeter servers can be managed from a single machine (client);
Test plan needn't be copied to all server machines - the client will send it to all the machines (servers); The picture below shows how it works.
The schematic diagram of the distributed (remote) testing, one client (master) and three servers is displayed on the image below: