Web Performance Tuning

Lin Wang, Ph.D.US Department of Education

Copyright [Lin Wang] [2004]. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement

appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.

1. Introduction Web-based systems consist of multiple

components working together:

Browser Web ServerApplication

ServerDatabase

HTTP request

HTTP response

2. J2EE and Queue Network Java 2 Enterprise Edition (J2EE) is a platform for

multi-tier Web systems. J2EE applications service HTTP requests through a

network of queues:

Browser Web Server WebContainer

EJBContainer

DataSource

Request flow

3. Performance Tuning Performance refers to how fast HTTP requests

are serviced. Performance becomes a critical issue when a Web

site processes large volume of requests. Performance bottlenecks are software/hardware

components that impede request service. Performance tuning is to identify and eliminate

performance bottlenecks.

4. Tuning Steps

1. Understand the application.

2. Design load tests.

3. Perform the load tests and collect data.

4. Analyze the data to identify bottlenecks.

5. Eliminate the bottlenecks.

6. Repeat Steps 3 – 5 until the performance is satisfactory.

5. A Sample Application: CUSER A customer service Web site, CUSER, is a J2EE application using IBM

WebSphere Application Server. CUSERV implements JSP and Servlet. CUSER consists of an IBM HTTP Server, WebSphere Application

Server (WAS), CICS Transaction Gateway (CTG), and DB2 on OS/390.

CUSER has four pools of runtime elements: HTTP server processes, Servlet threads, CTG worker threads, and DB2 tasks.

The pools are connected by three queues, HTTP transport, data source connections, CTG connections.

HTTP ServerWAS Webcontainer

CTGHTTP

transportqueue

Data sourcequeue

CTGconnection

queueDB2

WAS CTG

IE Browser

6. Load Test Design (I)Test Scenarios

Performance objectives:Response time must not exceed 5 seconds.

1000 users are to be concurrently serviced.

Test scenarios:Retrieve an existing customer record.

Create a new customer record.

7. Load Test Design (II)Test Procedure

Each scenario run takes 4 minutes and is iterated until the end of test.

Each user executes the same scenario throughout the test. Two scenarios are evenly distributed to the users.

The test starts with one user. The next user is added 10 seconds after the previous user’s entry, amounting to total of 1000 users.

User 1

Scenario 1

iteration

End

User 1000

Scenario 2

iteration

End

User 2 - User 999

Time

T1 T1+999x10 sec

8. Load Test Design (III)Instrumentation

Instruments: Load simulation: LoadRunner (Mercury) HTTP monitoring: LoadRunner (Mercury) J2EE monitoring: Introscope (Wily) System monitoring: Patrol (BMC)

Test environment:

Ethernet 100 mps

LoadRunner 1(Windows)

LoadRunner 2(Windows)

HTTP ServerWAS V4

(Sun) Introscope(Sun)

Patrol(Sun)

DB2(OS/390)

9. Load Test Design (IV)Data Collection Data collection interval:

System: Every 15 min. JVM: Every 30 sec. HTTP: Every response.

Test executionStart End

System data collection

t + 15 mint

JVM data collection

t + 30 sec

HTTP data collection

t + RTt

t

10. Load Test Design (V)Performance Metrics

HTTP metrics: Response Time (RT): The elapsed time between the submission of a

HTTP request and the receipt of the corresponding response. Throughput: The amount of data transmitted every second from the Web

site to the user. Error Rate: The ratio of failed to succeeded HTTP requests.

JVM metrics: JVM CPU usage JVM heap usage HTTP transport thread pool usage CTG response time Servlet response time

System metrics: CPU usage Memory usage Disk I/O

11. Test 1Pre-tuning Test Results (I) RT increased when user

load reached about 800. Throughput decreased in

the same time. Errors started to occurr.

Error types suggested problems on the server side.

12. Test 1Pre-tuning Test Results (II) CPU was saturated. JVM heap was saturated. Servlet thread pool was

saturated. Servlet response time was

increased. The results suggest a

memory resource contention.

13. Analysis:Bottlenecks and Tuning

System configurations bottlenecks: Connection pools.

Thread pools. Tuning:

HTTP Transport connection pools size: 45 => 108.

Servlet thread pool size: 200 => 120.

HTTP ServerWAS Webcontainer

CTGHTTP

transportqueue

Data sourcequeue

CTGconnection

queueDB2

WAS CTG

IE Browser

14. Test NFinal Test Results (I) RTs were less than 5

seconds except for the “startup” request.

Throughput stays adequate and stable.

No errors.

15. Test NFinal Test Results (II) CPU was 50% utilized. JVM heap usage showed

normal. Servlet response time was

reasonable. Servlet thread pool showed

normal usage (graph was missing).

16. Conclusions Performance tuning of Web-based systems is a

multi-variable and iterative process. A systematic planning is an effective approach. The tuning process involves:

Application review System review Test design Data collection and analysis System and application modification

Test design is crucial to successful performance tuning.