Performance testing presentation by Goranka Bjedov (Google)

Jmeter

Latency

General concept of latency in performance testing is the time it takes the request to reach the server from the client and then from the server back to the client, commonly known as the network latency. However, its not the only latency a request encounters. The flow of the request from web server to application server to DB is controlled by the use of queues and threads. So the time for which the request waits in the application server queue for a free thread to execute or in the database server for a connection pool, is also latent time for the request.

Normally under higher user loads, all the Application server threads and DB connection pools get used up and the incoming request queue up at these places, thus increasing the latency of the later requests. So it is important to have proper configuration settings for the queues and threads so that user requests do not queue up. For example, if the max thread count is set to a low value, then a high configuration application server may be able to handle the requests fast, but the response throughput will be limited by the number of threads available to process the requests.

Coming back to the network latency, this latency can be because of the following reasons:

• transmission delays (properties of the physical medium)
  
• and processing delays (such as passing through proxy servers or making network hops on the Internet)

Network tools like ping and tracert measure latency by determining the time it takes a given network packet to travel from source to destination and back. These tools can be used as a first step in finding out the network latency issues and then allowing the network team to fix the latency issue before the end users notice its effect.

Performance Testing Guidance for Web Applications

Performance Testing Guidance for Web Applications is one of the best resource available for download, which talks of the whole performance testing process right from determining performance goals, creating usage models, scripting, execution to effective reporting of the test results.
The concepts explained in the guide are independent of any particular load testing tool and can be used to understand and apply the learnings to any performance testing project.

Load testing SQL Server with Visual Studio 2005

Microsoft Visual Studio 2005 Team System includes a load-test tool that you can use for performance and stress testing of a Microsoft SQL Server 2005 Reporting Services deployment. The load-test tool runs the tests that you create, and optionally logs the data into a SQL Server 2005 database. You can monitor tests as they progress, review performance data after the tests are completed, and precisely determine what the threshold is for a specific report-server deployment.

Below is the link for the related article on Microsoft TechNet site:
http://technet.microsoft.com/en-us/library/aa964139.aspx

Load testing SQL Server with LoadRunner

For applications which create reports by mining through Databases, the main component that needs to be tested from performance point of view is the database itself.
Performance testing in these cases can be started quite early in the development life cycle, even without waiting for the User Interface to be ready. The stored procedures / SQL queries can be tested for response time, DB CPU & memory usage, etc, by simulating the calling of the queries directly to the DB server through LoadRunner with multiple Vusers. This will provide the developers early information on the performance of the queries and these tests can be conducted iteratively with the development fixes to fine-tune the SQL queries.

While testing the DB, care should be taken to have production-size database with similar number of records available. Also, volume testing can be done to test the degradation in response times for different volumes of data by increasing the volumes of data in a phased manner.
Also, the parameters in the queries should be varied enough to simulate different queries each time.

* For recording scripts to directly run queries on SQL Server, record using ODBC protocol through the SQL Query Analyzer.

LoadRunner Parameter Simulation

Lot of LoadRunner script issues are due to incorrect parameter settings. Most of the times when we run the script with VUGen, it works fine. However, while running the script in a controller scenario, we face issues such as sending wrong data for multiple users, running out of values (for unique data settings), etc.

So, to avoid these issues use the "Simulate Parameter" feature available for the File type parameters. You can validate the use of the different parameter values for multiple Vusers and iterations before running the script in a scenario. The parameter settings can be changed if there are any issues with the parameter usage and again validated.


For example, in the above images, it can be observed that the settings for the "NewParam" are set to "Unique, Once" and has only 3 data rows in the table. So if we try to simulate running the script with 4 Vusers, the fourth user does not have any values left in the table for its use and will fail. These kind of issues can be rectified with the help of the "Simulate parameter" feature.

Adding Upload Files to Loadrunner scripts

For a LoadRunner performance script which needs to upload some files in the business process, one way is to save the required files is to go to each and every Load Generator machine and save the files. However, if the file needs to be updated, it has to be again saved in all the load generators.

Instead of this use the "Add Files to Script" option available under the Files menu so that the files gets associated with the LoadRunner script and saved in the script directory.