Performance Tuning Guide - EMC Community Network

Measuring Performance
Analyzing multi-user tests
After completing your multi-user tests, analyze the following areas for bottlenecks:
• Determine which server or process consumed the most CPU or memory.
• Check the database server for queries that take a long time, deadlock or core dump alerts, and
top wait events. For Oracle user, use an AWR report for your analysis (See Assessing database
bottlenecks and dead waits, page 84).
• Check the J2EE layer for excessive garbage collections, which indicates a bottleneck in the
application server. If so, add additional JVM instances to improve load balancing.
• Check for bottlenecks indicated in the Content Server repository and BPM logs, and the
application server logs.
• Check for network bottlenecks indicated by bandwidth exhaustion or by exceeding the maximum
number of packets per second that can be transferred. Even though network bandwidth is not
exhausted, a typical network card can only handle definite number of packets a second. In this
case adding additional network cards can help.
When addressing a problem area, incrementally make one change at a time so that you can
understand the impact of the change, then rerun the test. Depending on the result of the rerun
test, you can either apply or reject your change.
Avoiding multi-user test worst practices
The following provides activities to avoid during multi-user testing:
• Do not turn on excessive logging or tracing. The volume of log files generated in a multi-user
load test makes analysis of results difficult.
• Do not synchronize users to execute an operation at the same time. Interpretation of these types of
results regarding the true capability of your system can be misleading.
• Avoid simulating super-users. Using a few super-users to process requests is not the same as
spreading the same number of requests over a larger set of normal-users. For the normal-user
scenario, each user creates a unique backend session with caching and history being tracked under
that particular session. The purging and reuse of cache data is based on the wall-clock request
time of that user session. A super-user session violates most of the built-in design algorithms
because request times are unrealistically condensed.
• Do not exceed 80% CPU usage or memory capacity on your servers. During normal usage,
operating systems require 20% excess capacity to handle naturally occurring usage spikes.
Red-lining servers generates results that are misleading and bring no value to the overall
validation of the system. Be prepared to add servers when 80% capacity is reached.
• Avoid running multi-user testing on unstable builds. Make sure your single user testing is
acceptable before doing multi-user testing.
EMC Documentum xCP 1.0 Performance Tuning Guide 83