1. Introduction

Performance of a Web site is analyzed from different viewpoints. The Web server performance depends on several factors: hardware & software platform, operating system, server software, network bandwidth and workload. There are various well-known methodologies available for performance evaluation of computer systems. The overall performance of any system mainly depends on three models:

> Workload model,
> Performance model,
> Cost model.

The workload model captures the resource demands and workload intensity characteristics of the load brought to the system by the different types of transactions and requests.

The performance model is used to predict response times, utilization, and throughputs, as a function of the system description and workload parameters.

The cost model accounts for software, hardware, network-communications and support expenditures. The scope of this paper is Workload model

2. Performance Testing

Performance testing is a class of tests implemented and executed to characterize and evaluate the performance related characteristics of the target-of-test such as the timing profiles, execution flow, response times, and operational reliability and limits. Different types of performance tests, each focused on a different test objective are implemented throughout the Software development life cycle (SDLC). Earlier in the architecture iterations, performance tests are focused on identifying and eliminating architectural-related performance bottlenecks. In the construction iterations, additional types of performance tests are implemented and executed to tune the software system to handle high load and stress conditions. (Large numbers of transactions, clients or volumes of data)

In Performance Testing the following are the types of tests

Benchmark testing:

Compares the performance of new or unknown target-of-test to a known reference standard such as existing software or measurements.

Load testing:
The test used to validate the operational limits of a web application under varying workloads while the system-under-test remains constant. Measurements are usually taken based on the workload throughput and in-line transaction response time.

Stress testing:
The test used to evaluate how the web application responds under abnormal or extreme conditions. Stresses on the web application may include extremely high number of users and resources.

3. Work load models

The workload is sum of the total burden of activity placed on the web application to be tested. This burden consists of a certain number of virtual users who process a defined set of transactions in a specified time period. Assigning the proper workload is one of the most crucial parts of any performance analysis.

Types of workload

1) Steady state work load
2) Increasing workload
3) Scenario based workload

3.1. Steady state workload

In this method a constant number of virtual users are run against the web application for the entire duration of the test. This method provides the exact response time and throughput measurements for a given number of users. This type of workload is often used for the stress tests.



A steady state workload, however does not replicate real-world conditions like number of simultaneous users changes.

3.2. Increasing workload

In this method the workload, which is increasing will help the testers to find the limit of the web application's work capacity. Initially load testing is done with minimum number of virtual users. Gradually virtual users are added to the workload. This will continue until the web application response time exceeds the permitted limit or in a worst case, the application crashes. The tester can identify the maximum number of simultaneous users the web application can support.



3.3. Scenario-based workload

This model is used to achieve an exact real-world scenario's by varying the number of virtual users run during a test, depending on the peak time of the day. The following figure shows the typical scenario based workload with extreme highs and lows at certain times depending upon the traffic.

For example: - CITI BANK advertise special offer, or as well as during general holiday.



4. Performance Requirements parameters For Internet Applications

The following parameters are
(a) Capacity
(b) Throughput
(c) Response Time
(d) Consistency
(e) Scalability

4.1. Capacity

Capacity means whether the web application is able to handle large number of concurrent users. Ex: www.google.com is a search engine, able to handle several thousands of concurrent requests simultaneously. For web application, the Capacity will be depending on the hard ware configuration of the server. The capacity often varies directly with the amount of memory available to maintain the session information for each end -user.

4.2. Throughput

Throughput means whether the number of clients requests processes within a certain time. The unit of measurement is requests per second. Throughput may also be measured in terms of visitors per day. The main role of Throughput is to identify the performance bottlenecks, improving applications and performance of the system.

The following figure shows the characteristics of throughput versus user load.



The above figure gives the detail information about the throughput vs. user load at the Starting point the throughput will increase according to the user load and gradually the throughput of a typical Web site increases proportionally at the initial stages of increasing load. However, due to limited system resources, throughput cannot be increased indefinitely. It will eventually reach a peak, and the overall performance of the site will start degrading with increased load. Maximum throughput, illustrated by the peak of the graph in Figure 1, is the maximum number of user requests that can be supported concurrently by the site in the given unit of time.

The throughput value varies from site to site. It mainly depends on the complexity of the application. For example, a Web site consisting of only static HTML pages may be able to serve many more requests per second than a site serving dynamic pages.

Response Time

Response time is the time from when the browser has finished sending a request to when it starts receiving the response from the server. Response time and capacity both are inversely proportional to each other. More end-users it supports on the server the response time will be slower, as they all compete for processor and memory resources. On the hardware side, web response time can be improved by using a faster processor on the server, removing any bandwidth bottlenecks.



The above shown graph gives the detail information about the Response time versus user load. At the start point the response time is very less and it will increase according to the user load. Gradually the response time of a Web site will increases proportionally according to the increasing load.

4.4. Consistency

The response time (whatever its level) has to be consistent from one interaction to the next. Consumer-oriented Internet applications, such as e-commerce systems, must ensure that response times are consistent within a narrow band, otherwise shoppers will become frustrated with unexpected delays

4.5. Scalability

Scalability is the ability of a system to grow from a small number of users to a large number of users without encountering the major bottlenecks that make performance unacceptable. Some applications, which are developed, may perform well in the development lab with a few users, or even under testing with a few hundreds of users, but when they are launched in the real world with several thousands of users, the system simply breaks down.



The above shown Graph gives more information about the scalability.

For example: -Consider three web pages x, y, z the graph shows their response time versus user load Web page-X represents theoretical scalability for an ideal web application, the response time is increasing in perfectly linear proportion to the number of users. This is not possible in the real world. Web site Y represents an acceptable level of practical scalability where the response time increases significantly from the ideal level .Web page Z is not scalable why because the response time for this web page rises so disproportionately to the number of users that the web application crashes.

5. Real time testing scenario Graphs

The graphs depicted below are the results of the Performance Tests done in Real time scenario. The Performance test was carried by testing of a website using the Rational Robot, which is one of the tools of Rational suite enterprise.

5.1. PERFORMANCE REPORT



Performance reports contain the following information:

> Cmd ID: The command ID associated with the response.
> NUM: The number of responses for each command ID (the number of times each command ID appears in the test log).
> MEAN: The arithmetic mean of the response times of all commands and responses for each command ID.
> STD DEV: The standard deviation of the response times of all commands and responses for each command ID.
> MIN: The minimum response time for each command ID.
> 50th, 70th, 80th, 90th, 95th - The percentiles of the response times of all responses for each command ID.
> MAX - The maximum response time of all responses for each command ID.



> Cmd ID - The command ID associated with the response.
> Ending TS - The ending timestamp of the response. This timestamp corresponds to the value of the read-only timestamp variable for the response. The timestamp is the interval ending timestamp as defined by the Time Period report option.
> Response - The response time in milliseconds.
> Status - Displays Pass or Fail to indicate whether the response passed or failed.
> Virtual Tester - The virtual tester corresponding to the response.
> Script - The name of the test script corresponding to the response.

5.3. COMMAND STATUS REPORT



The command ID associated with the response.
> NUM - The number of responses corresponding to each command ID. This number is the sum of the numbers in the Passed and Failed columns.
> Passed - The number of passed responses for each command ID (that is, those that did not time out).
> Failed - The number of failed responses for each command ID that timed out
> (That is, the expected response was not received).
> % Passed - The percentage of responses that passed for that command ID.
> % Failed - The percentage of responses that failed for that command ID.

6. Conclusion

Web based applications are more complex compared to the conventional client-server applications due to many unknowns and uncertainties. Among many complexities, performance testing is one of the important activities in E-commerce application development life cycle. The user and designers perceptions are entirely different and difficult to bridge the gap.