Web Performance Tuning Lin Wang, Ph.D. US Department of Education Copyright [Lin Wang] [2004]. This...
-
Upload
jagger-hilbert -
Category
Documents
-
view
212 -
download
0
Transcript of Web Performance Tuning Lin Wang, Ph.D. US Department of Education Copyright [Lin Wang] [2004]. This...
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.