270 likes | 384 Views
UIUC - CS527 - fall 2007 student presentation Performance testing Java servlet-based Web applications: A guide for software test engineers. by Len DiMaggio, Software QE Engineer and Manager, IBM (February 16, 2004) -presented by Adrian Olaru-.
E N D
UIUC - CS527 - fall 2007student presentation Performance testing Java servlet-based Web applications: A guide for software test engineers • by Len DiMaggio, Software QE Engineer and Manager, IBM (February 16, 2004) -presented by Adrian Olaru- UIUC - CS 527 - fall 2007
What can you expect to achieve from this presentation ? You will understand: • why web applications performance testing is important • how servlet-based web applications work • what components are critical for testing • how to spot potential problems and how to fix them Hopefully you will find immediate practical use of the ideas presented here UIUC - CS 527 - fall 2007
Overall structure of the paper / presentation • Step 1: Understand what’s special about servlet performance • Step 2: Consider the performance test factors before testing the servlet • Step 3: Planning the tests • Step 4: Executing the tests • Closing thoughts UIUC - CS 527 - fall 2007
The importance of performance testing • Direct impact on application success: if you make clients wait, they’ll take their business elsewhere • Quick response to various kinds of requests: today’s web applications handle complex data • Ability to scale to increasing number of requests UIUC - CS 527 - fall 2007
Step 1: Understand what’s special about servlet performance Servlets overview: • Servlets are run by a Java-enabled Web/J2EE server • Servlets are managed by a container – therefore container configuration and performance is very important • Servlets are in the Middle Tier of multi-tier Web applications: Client Tier, Middle Tier, Back-End (EIS) Tier. UIUC - CS 527 - fall 2007
Simplified Web/J2EE Platform UIUC - CS 527 - fall 2007
What servlets do • Generate dynamic content - most of the time the data comes from a database • Implement a request-response model - http is a stateless protocol • Run unattended for long periods of time! Therefore servlet’s management over system resources is of utmost importance UIUC - CS 527 - fall 2007
Step 2: Consider performance test factors before testing the servlet Consider the testing environment and the optimum testing sequence Validate the testing environment: • Hardware: operational characteristics of your network • Software: virus scanning, shared directories, components’ configuration UIUC - CS 527 - fall 2007
Important aspects in testing environment • Routing: servlet’s requests to remote components should use the best network path; check with traceroute (Unix) or tracert(Windows) • Logging: set it at the customer’s appropriate level (production mode) • Turnoff system automatic tasks (such as automatic software updates) • Configure memory correctly! For java, make sure you use “java -Xmx” option. Example: “java –Xmx640M MyTest” will allow MyTest to use at most 640MB if needed; if not specified, the default maximum allowed is only 64MB! UIUC - CS 527 - fall 2007
Performance tests are complex equations • Define variables and constants that make up the tests • Establish a repeatable pattern of test results by using one set of values for variables and constants • Change one variable and observe the effect on results – avoid the temptation to change multiple variables in the same time! UIUC - CS 527 - fall 2007
When to execute performance testing • Common practice: start after functional, integration and system tests, when the application is sound –> it is too late • Better approach: start as early as possible • When to stop? NEVER UIUC - CS 527 - fall 2007
Step 3: Planning the tests Analyze / measure: • Servlet longevity • Data movement rate • Servlet profiling • System resource consumption • Efficiency of software integrations UIUC - CS 527 - fall 2007
Measure Servlet Longevity • Remember: • servlets run unattended for long periods of time • servlets are instantiated by the servlet container • Is performance consistent over time? Check servlet throughput, response time, memory consumption. UIUC - CS 527 - fall 2007
Measure data movement rate • Measure the rate at which the servlet can accept, process and serve data. • Run capacity tests: apply increasing levels of of usage/traffic • See how variations in test data affect performance: data size, data formats. UIUC - CS 527 - fall 2007
Servlet profiling – find out where the servlet is spending its time Focus on: • Data collection • Data aggregation and calculation • Data reporting: how is the servlet outputting the data to the user • Caching: see whether the servlet is taking advantage of caching UIUC - CS 527 - fall 2007
Measure system resource consumption It must rise and fall with the traffic level • Memory: • make sure garbage collector is working properly • you can still have memory leaks in java! They occur when objects are reachable but no longer used by the applications • monitor memory usage with specialized tools: OS provided: Task Manager (Windows); sar (Solaris); vmstat, top (Unix) Commercial: IBM Rational Purify (multiple OS) UIUC - CS 527 - fall 2007
Measure system resource consumption (2) • Disk capacity and I/O rates: • Logging level: keep it at a minimum when testing performance • Temporary files: as little as possible when testing performance • Data cleaning tasks also affect performance UIUC - CS 527 - fall 2007
Verify the efficiency of software integrations Dealing with the databases – the most common and important integration point concerning a servlet • Global queries: try to avoid them, narrow the scope of the query to minimum needed • Amount of data retrieved: query only the data shown on the screen! (Student comment: if performance still not good, change the UI layout such as smaller amounts of data are requested upon an UI action) UIUC - CS 527 - fall 2007
Dealing with the database connections • Reuse database connections when possible: getting a database connection is expensive, performance and a system resource wise! • Do not leave open connections hanging around: it may take a while for the garbage collector to clean them. UIUC - CS 527 - fall 2007
Bad code example when dealing with database connections try { <open connection> <read data> <close connection> } catch( exception ) { <log error, return> } UIUC - CS 527 - fall 2007
Good code example when dealing with database connections java.sql.Connection myCon = null; try { myCon = <open connection> <read data> } catch( exception ) { <log error, return> } finally { if( null != myCon ){ <close connection> } } UIUC - CS 527 - fall 2007
Step 4: Executing the tests • Stage 1: verify the subsystems and perform low-impact aerobics • Stage 2: vary the equation #1: Load testing • Stage 3: vary the equation #2: Performance testing • Stage 4: conduct ongoing “health checks” UIUC - CS 527 - fall 2007
Stage 1: verify the subsystems and perform low-impact aerobics Ensure that the application “can walk”: • Reexamine functional tests: look at the subsystems in isolation and see how efficient it returns the results • Decide whether to replace subsystems with stubs • Perform low impact aerobics / verify longevity: run a single thread of traffic to flush out silly bugs like counters that do not reset; run it for a long time to check the sustainability of the system resources use. UIUC - CS 527 - fall 2007
Stage 2: vary the equation #1: Load testing Ensure that the application “can run”: • Define a test configuration and establish a baseline: hardware, software configuration, test data, traffic usage level, time length for running the test • Vary the data and number of users: • vary the test data: the mix of data should be an approximation of what users will do • vary number and characteristics of test users: increase the number of users, group users in classes of users based on the actions they perform • Compare results against baseline. • Do not vary both data and users in the same time! UIUC - CS 527 - fall 2007
Stage 3: vary the equation #2: Performance testing (student comment) Ensure that the application “can sprint” • Test at the boundaries: • minimal and maximal hardware; quantify the application performance on an optimal configuration • distributed subsystems: from multiple subsystems sharing the same server, to one server for each subsystem. UIUC - CS 527 - fall 2007
Stage 4: ongoing “health checks” • Run periodic checks: this ensures that the application works with the latest updates for the OS, Java JRE, Web/J2EE server, Database. • Remember: it’s easy to fall behind just by standing still! UIUC - CS 527 - fall 2007
Closing thoughts / Questions • Java servlets are an important milestone in the evolution of Internet-based software. • Remember to performance test your applications! ----------- Some of the questions that were asked: • how is performance testing treated in academia? • what container testing tools people use? • what tools people use for caching and stubbing in web applications? I hope you enjoyed the presentation. THANK YOU! UIUC - CS 527 - fall 2007