1. 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.

2. 1. Introduction Web-based systems consist of multiple components working together:

3. 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:

4. 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.

5. 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.

6. 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.

7. 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.

8. 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 users entry, amounting to total of 1000 users.

9. 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:

10. 9. Load Test Design (IV) Data Collection Data collection interval: System: Every 15 min. JVM: Every 30 sec. HTTP: Every response.

11. 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

12. 11. Test 1 Pre-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.

13. 12. Test 1 Pre-tuning Test Results (II) CPU was saturated. JVM heap w as saturated. Servlet thread pool was saturated. Servlet response time was increased. The results suggest a memory resource contention.

14. 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.

15. 14. Test N Final Test Results (I) RTs were less than 5 seconds except for the startup request. Throughput stays adequate and stable. No errors.

16. 15. Test N Final 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).

17. 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.