Engineering for Internet Applications Project 2 Tooba Aamir 396447 Kashif Iqbal 554377

University of Melbourne (Semester-2 2011) Department of Computer Science and Software Engineering

Course title Engineering for Internet Applications

Submitted by: Tooba Aamir 396447 Kashif Iqbal 554377

Dated October, 27 2011

Engineering for Internet Applications Project 2 Tooba Aamir 396447 Kashif Iqbal 554377

1. Introduction:
Web Applications / sites in the current information age are important and essential part of any business as they are great source of promoting any business. Almost all the businesses irrespective of the type are relying on the internet to promote their businesses. From the client/user perspective internet business is also a preferred choice of purchasing, getting information and deciding about their choices. Hence, under these client preferences the businesses are bound to keep their internet services efficient, up to date and available 24/7. Undoubtedly, a web site seen as luxury at one time has turned into necessity. From the web application engineering and IT services provided perspective it has made this domain technically more challenging with overwhelming demand on the performance and quality of services. . Aim: Aim of this project is to develop and apply a performance test methodology for a web application and to demonstrate the performance characteristics of the application under given scenarios. . Performance Testing Environment: For this purpose major component of the environment is a Web Server: Apache Tomcat 7 on which the Test Server application provided is deployed. Apache Tomcat is an open source software implementation of the Java Servlet and Java Server Pages technologies. Test Server is specific server provided by the University for this Project. This server was ideally suppose to be installed on the network and used in the computer lab but due to some problems, it has been allowed to deploy the server on the local machine and use for performance testing. Effort are made to keep it as close to real environment as possible, details to follow in the paper. Performance Testing tool: JMeter, a performance testing tool is an Apache Jakarta project that can be used as a load testing tool for analyzing and measuring the performance of a variety of services, with a focus on web applications. It performs automated and functional testing for application along with performance, availability testing, and functionality testing on application to make sure that application meets desired expectations. Also we used MS Excel to present data collected by JMeter. c. Description: As said in aim of this project, we need to test the performance of a web application. For this a 'Test Server' web application is provided in WAR file form that is installed on local-host. This Test Server has a single API i.e. 'TestServer/Process?param1=X&param2=Y' where X and Y are integers from 0 to 100 inclusive. This Test Server is supposed as a web application performing differently for each set of input parameters. Moreover it simulates load on the server and responds differently, in terms of processing delay and size of response. To simulate and test server under different load scenarios three classes of users are made. Each class holds different type of request making patterns. First class of users, Class A, makes a request every 1 to 2 minutes, with sessions of 10-20 minutes, varying from user to user. These users select random value of X and Y for each request and if previous request has not completed when a new request is to be made, then terminates the session early. Second is Class B, user from this class chooses a value of X and Y randomly from the range 0 to 50 (for both X and Y), then makes between 50 to 100 consecutive requests as quickly as possible with the same value of X and Y. Similar to previous class new request is made only when the response of the current request is received. Third Class i.e. Class C is mostly similar to Class B, only difference is that each user for a single randomly chosen value of X makes a query for Y=[0,10,20,...,100] consecutively. So using all these details requirement is to determine the different classes of response and summarise their statistical properties in terms of response latency and response size. Specific focus is on following: 2

Engineering for Internet Applications Project 2 Tooba Aamir 396447 Kashif Iqbal 554377

Behaviour of server if only Class A users access it, with no more than 5% terminating their session. How in this scenario latency of their requests increases as the number of users. Deducing maximum number of Class A users that can use the system in this case. Maximum throughput of Class C users Assuming that load on server follows proportion 50%/30%/20% for Class A/B/C user, how many concurrent users server can handle without more than 5% Class A users terminating their session early. Ensuring a case where at least 20 Class A users, with only less than 5% terminating their session are serviced, how many Class B users can be entertained at the same time.

2. Test Case Design:

. Assumptions: While carrying out the tests for web server performance the University Lab Server has not responded and it crashed more than often due to some technical problem in computer lab as stated above. Hence, the tests are carried out in the local machine using localhost. However, the performance and response time is not very realistic for checking the performance of any web application / server. Hence, in order to simulate the performance near to realistic results, the methodology / innovation adopted by us is to reduce the response time of the JMeter in HTTP Requests Default. This when tested has failed the requests in quick time which can be seen as latency of the network. However, the value used in different tests is different as per the requirements of the scenario. Secondly, it is assumed that in a thread group especially for class B user in which the user repeats his request continuously for 50-100 times; after this user is finished, any new requests is from different user. . Design Decisions: Before carrying out the actual tests we first designed the cases and requirement of each case. This has helped us while deciding about the features which are required to be used during the actual implementations. The broad cases we need to design as part of requirement analysis and subsequent implementations in jmeter are as under: Mechanism to change value of X and Y parameters. Mechanism to generate loops in the jmeter for initiating the request, selecting and initiating the request both sequentially and randomly. Designing of mechanism for changing the values of X and Y and X or Y, Need facility to set the session time for each user. Mechanism to simulate the behaviour of the user as defined in the project requirements as per classification of the users classes i.e A, B and C. Build Test Plans as per the behaviours of the different classes of the users. Above are the overall requirements we have considered which will be used in the implementation. Different results and analyses based on the data will be presented in the Test and Analysis part. . Performance Parameters: Another aspect of the design is to decide what all parameters are required to be analysed for accruing the beneficial results from the experiments. This aspect has also helped us in implementation of different features in the jmeter. Following important parameters are essentially required to be saved for analyses. However, it is pertinent to mention that all the mentioned parameter are not available directly in the jmeter and some are will be derived, the formula to drive different scenario will be given in the relevant part of the paper, here we are mentioning the important ones only: Latency 3

Engineering for Internet Applications Project 2 Tooba Aamir 396447 Kashif Iqbal 554377

Response time Response size Load Throughput

. Users Simulation: The simulations of three classes of users are done through the Thread Group implementation. Each thread group is made up of different features of JMeter as per the users profile. Class A Users: A separate Thread Group was made to simulate Class A type users as per the requirement given above. Configuration element HTTP Request Default added to read the requests. Among the logic controller Random Order Controller was selected to randomly select, among the available requests and initiate. Under this logic controller HTTP requests were added. Each request was introduced with two parameters i.e. param1 and param2 with different combination of values. Additionally, scheduler was used to set the session time of user. Class B Users: For this class depiction HTTP Request Default with Random Order Controller is used. Under the Random Order Controller different loop controller are used and each loop with value from 50-100 to depict the behaviour of this class of user. However, no session time is required for this class of user. Class C Users: Configuration of this class is almost as per class B with exception that each request is not generated continuously for the number of time as given in Class B.

3. Test Case Implementation:

Following Snap shots show the implementation of this design:

Engineering for Internet Applications Project 2 Tooba Aamir 396447 Kashif Iqbal 554377

Test Case for Class A Diagram shows thread group for Class A. To Implement desired conditions first A Random order controller was selected and 20 different Http Request pages, with different random values of X and Y for each request, were created under this Random order Controller. So that each time different Http request is send by user. To set Session time for each user Duration was set as 900 sec (i.e. 15 min.). And to check that previous request is made or not response time-out is set as 6000 msec., i.e. 6 sec. We set it less than 12 min. because we ran all tests on local host to simulate the correct response. Then again to meet condition that if response not said in time-out period user will terminate the session we we set action of thread as that if sampler error then stop that thread. Now after meeting all these conditions we simply increased concurrent threads, i.e. concurrent number of users to implement different test cases. Test Case for Class B Diagram shows thread group for Class B. To Implement said conditions first like Class A, a Random order controller was selected and containing 6 Loop Controllers to produce 50,60,70,80,90,100 consective Http Requests respectivly. And each loop have 1 Http Request page so tht all requests in loop have same X and Y values. No session time was set for each user and also no time-out period as user waits to receive the request before making next request. After setting all these conditions we simply increased concurrent threads, i.e. concurrent number of users to implement different test cases. Test Case for Class C This is diagram of thread group for Class C. It is similarr to Class B, but 5

Engineering for Internet Applications Project 2 Tooba Aamir 396447 Kashif Iqbal 554377

difference is that instead of single Http Request per Loop Controller there are 10 requests each with same random Value of X but Y = [10,20,30,40,50,60,70,80,90, 100] respectively for each. Random order controller selects loop controller and then sends all Http Requests from than controller before moving to next loop. Again no session time was set for each user and also no time-out period as user waits to receive the request before making next request. After setting all these conditions we simply increased concurrent threads, i.e. concurrent number of users to implement different test cases. In this way using different constraints proved in thread groups from controllers all test plans were implemented using different combinations of concurrent threads for each test case. To record all data from these tests different listeners are added to each thread group and also some overall listeners to get overall results independent of user classes. Some of the listeners used are: View Result Tree: Shows a tree of all sample responses, allowing to view the response for any sample. In addition to showing the response, the time it took to get this response, and some response codes are also shown. Graph Result: Generates a simple graph that plots all sample times. Along the bottom of the graph, the current sample (black), the current average of all samples(blue), the current standard deviation (red), and the current throughput rate (green) are displayed in milliseconds. View Result in Table: Creates a row for every sample result. Like the View Results Tree Aggregate Report: Creates a table row for each differently named request in test. For each request, it totals the response information and provides request count, min, max, average, error rate, approximate throughput (request/second) and Kilobytes per second throughput.

4. Results and Analysis: Different test were conducted using given design and data collected in result of these tests helps to study stress measurements of test server. Below are some aggregated results of test cases we conducted: Our first test was to check general latency and response size of Test Server despite of its users classes. We did this test on bases of values of 'X' and 'Y'. This test was conducted using 3000 users with random values of X and Y. Test results showed following trends:

Second Test comprises of fact that if only Class A users can access Test Server then How many concurrent users server can sustain ensuring that on average not more that 5% 6

Engineering for Internet Applications Project 2 Tooba Aamir 396447 Kashif Iqbal 554377

terminate their session. For this test we experimented with different range of users and results showed that: Total Users Trial 1 Trial 2 Trial 3 Trial 4 30 40 60 65
provided only 5% terminate session
6.00% 5.00% 4.00%

Error 3.57% 4.86% 4.74% 5.02%

Maximum Users of 'Class A' sustaind

Error (%)

3.00% 2.00% 1.00% 0.00% 30 40 60 65

Error

Users of 'Class A'

These results show that although in range of 40-60 users error rate is high i.e. on average 4.8% users were terminating sessions but as user limit crossed 65 error was more than set limit. Test 3 is simply to test maximum throughput of users of class C. For this throughput of class C with different number of users was tested in different scenario i.e. with different number of users and their request frequency 10 by each user. Total Users Trial 1 Trial 2 Trial 3 Trial 4 50 80 110 140 Throughput/sec 17.6 24.60/sec 27.06/sec 31.0/sec

Test 4 is to measure how much load Test Server can maintain without more than 5% users of class A dissatisfying. But conditions are that user load proportion on server is 7

Engineering for Internet Applications Project 2 Tooba Aamir 396447 Kashif Iqbal 554377

50%/30%/20% for Class A/B/C user. Class A Class B Class C Total Users Trial 1 Trial 2 Trial 3 Trial 4 Trial 5 25 40 50 55 60 15 24 30 33 36 10 16 20 22 24 50 80 100 110 120 Error in Class A 2.16% 8.77% 4.49% 5.99% 7.60%

Sustainbility of Server
with given user ratio
140 120 100

Total Users

80 60 40 20 0 2.16% 8.77% 4.49% 5.99% 7.60%

Class C Class B Class A

Error in 'Class A'

This result shows that maximum 110 users can be sustained with given ratio. And for this Class users are between 55-60.

Test 5 is to measure maximum load of Class B users Test Server can maintain but condition that at least 20 Class A users, with only less than 5% terminating their session are serviced.

Class B Trial 1 Trial 2 Trial 3 Trial 4 Trial 5 Trial 6 30 60 90 100 110 120

Total Users 50 80 110 120 130 140

Error in Class A 1.81% 3.53% 3.64% 3.69% 4.87% 6.99%

Engineering for Internet Applications Project 2 Tooba Aamir 396447 Kashif Iqbal 554377

Sustainbility of Server
(Class A users = 20)
8.00% 7.00% 6.00%

Error Rate

5.00% 4.00% 3.00% 2.00% 1.00% 0.00% 30 60 90 100 110 120

Error in Class A

Users in Class B

The graph shows that as the number of users from class B increases between 110-120 error rate in Class A users shoot up to 7% approximately. So at maximum Server can sustain with B Class users less than 120 with A Class users 20. Server Response: Trial 2:

Trial 3:

Trial 5:

Engineering for Internet Applications Project 2 Tooba Aamir 396447 Kashif Iqbal 554377

Above given graphs show throughput (green colour) under given test. After conducting all these tests and reviewing differences in user classes following trends were generally observed: Class A:

This graph shows the throughput and average data rate of Class A. It can be seen from graph that throughput starts to rise from minimum to maximum graduallt but towards end there is minor declin. On other hand in data rate it reaches its maximum quite quickly but then with minor decrease retains almost same position throughout. This experiment was conducted using 60 concurrent users. And Aggregate report shows 4.68% error.

Class B:

10

Engineering for Internet Applications Project 2 Tooba Aamir 396447 Kashif Iqbal 554377

As graph shows that throughput of Class B is maximum in beginning but as time passes due to increase of load throughput begins to decline. But at the same time average keeps increasing. This experiment was conducted using 50 concurrent users. But same trend is observed as number of users increase. Class C:

This is graph of Class C users with 60 users. In Class C trends of throughput are same as Class B users, but difference is that decline in Throughput is more rapid in Class C than Class B.

5. Conclusion 11

Engineering for Internet Applications Project 2 Tooba Aamir 396447 Kashif Iqbal 554377

12