1 Performance Testing The performance testing is a measure of the performance characteristics of an application. The main objective of a performance testing is to demonstrate that the system functions to specification with acceptable response times while processing the required transaction volumes in real-time production database. The objective of a performance test is to demonstrate that the system meets requirements for transaction throughput and response times simultaneously. The main deliverables from such a test, prior to execution, are automated test scripts and an infrastructure to be used to execute automated tests for extended periods. 1.1 What is Performance testing? Performance testing of an application is basically the process of understanding how the web application and its operating environment respond at various user load levels. In general, we want to measure the latency, throughput, and utilization of the web site while simulating attempts by virtual users to simultaneously access the site. One of the main objectives of performance testing is to maintain a web site with low latency, high throughput, and low utilization. 1.2 Why Performance testing? Performance problems are usually the result of contention for, or exhaustion of, some system resource. When a system resource is exhausted, the system is unable to scale to higher levels of performance. Maintaining optimum Web application performance is a top priority for application developers and administrators. Performance analysis is also carried for various purposes such as: • During a design or redesign of a module or a part of the system, more than one alternative presents itself. In such cases, the evaluation of a design alternative is the prime mover for an analysis. • Post-deployment realities create a need for the tuning the existing system. A systematic approach like performance analysis is essential to extract maximum benefit from an existing system. • Identification of bottlenecks in a system is more of an effort at troubleshooting. This helps to replace and focus efforts at improving overall system response. • As the user base grows, the cost of failure becomes increasingly unbearable. To increase confidence and to provide an advance warning of potential problems in case of load conditions, analysis must be done to forecast performance under load. Typically to debug applications, developers would execute their applications using different execution streams (i.e., completely exercise the application) in an attempt to find errors. When looking for errors in the application, performance is a secondary issue to features; however, it is still an issue. 1.3 Performance Testing Objectives The objective of a performance test is to demonstrate that the system meets requirements for transaction throughput and response times simultaneously. This infrastructure is an asset and an expensive one too, so it pays to make as much use of this infrastructure as possible. Fortunately, this infrastructure is a test bed, which can be re-used for other tests with broader objectives. A comprehensive test strategy would define a test infrastructure to enable all these objectives be met. The performance testing goals are: • End-to-end transaction response time measurements. • Measure Application Server components performance under various loads. • Measure database components performance under various loads. • Monitor system resources under various loads. • Measure the network delay between the server and clients 1.4 Pre-Requisites for Performance Testing We can identify five pre-requisites for a performance test. Not all of these need be in place prior to planning or preparing the test (although this might be helpful), but rather, the list defines what is required before a test can be executed. First and foremost thing is The design specification or a separate performance requirements document should : • Defines specific performance goals for each feature that is instrumented. • Bases performance goals on customer requirements. • Defines specific customer scenarios. Quantitative, relevant, measurable, realistic, achievable requirements As a foundation to all tests, performance requirements should be agreed prior to the test. This helps in determining whether or not the system meets the stated requirements. The following attributes will help to have a meaningful performance comparison. • Quantitative - expressed in quantifiable terms such that when response times are measured, a sensible comparison can be derived. • Relevant - a response time must be relevant to a business process. • Measurable - a response time should be defined such that it can be measured using a tool or stopwatch and at reasonable cost. • Realistic - response time requirements should be justifiable when compared with the durations of the activities within the business process the system supports. • Achievable - response times should take some account of the cost of achieving them. Stable system A test team attempting to construct a performance test of a system whose software is of poor quality is unlikely to be successful. If the software crashes regularly, it will probably not withstand the relatively minor stress of repeated use. Testers will not be able to record scripts in the first instance, or may not be able to execute a test for a reasonable length of time before the software, middleware or operating systems crash. Realistic test environment The test environment should ideally be the production environment or a close simulation and be dedicated to the performance test team for the duration of the test. Often this is not possible. However, for the results of the test to be realistic, the test environment should be comparable to the actual production environment. Even with an environment which is somewhat different from the production environment, it should still be possible to interpret the results obtained using a model of the system to predict, with some confidence, the behavior of the target environment. A test environment which bears no similarity to the actual production environment may be useful for finding obscure errors in the code, but is, however, useless for a performance test. 1.5 Performance Requirements Performance requirements normally comprise three components: • Response time requirements • Transaction volumes detailed in ‘Load Profiles’ • Database volumes Response time requirements When asked to specify performance requirements, users normally focus attention on response times, and often wish to define requirements in terms of generic response times. A single response time requirement for all transactions might be simple to define from the user’s point of view, but is unreasonable. Some functions are critical and require short response times, but others are less critical and response time requirements can be less stringent. Load profiles The second component of performance requirements is a schedule of load profiles. A load profile is the level of system loading expected to occur during a specific business scenario. Business scenarios might cover different situations when the users’ organization has different levels of activity or involve a varying mix of activities, which must be supported by the system. Database volumes Data volumes, defining the numbers of table rows which should be present in the database after a specified period of live running complete the load profile. Typically, data volumes estimated to exist after one year’s use of the system are used, but two year volumes or greater might be used in some circumstances, depending on the business application. . 1 Performance Testing The performance testing is a measure of the performance characteristics of an application. The main objective of a performance testing. objectives of performance testing is to maintain a web site with low latency, high throughput, and low utilization. 1.2 Why Performance testing? Performance