Performance Tuning Guide - EMC Community Network
Performance Tuning Guide - EMC Community Network
Performance Tuning Guide - EMC Community Network
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Designing the Application<br />
• Only track essential events in the audit trail. Auditing can slow down response times and increase<br />
CPU usage on the Content Server and database.<br />
• Partition the workload and avoid bottlenecks.<br />
Preventing high load user actions<br />
Individuals can engage in certain activities that put excessive demands on the system and affect<br />
overall system performance. For example, a case insensitive partial keyword search across several<br />
types can lock the database until the query can be completed. Running a resource-intensive job or<br />
report can also slow down system performance.<br />
Design your application to prevent high load user scenarios from occurring. During development<br />
and testing, devise scenarios that can slow down system performance and design these scenarios<br />
out of your application.<br />
Improving login speed<br />
The user login operation takes 2-10 seconds to complete. The landing page that opens after a user<br />
logs in affects login time the most. For fast logins, set the landing page to the default page or to<br />
a blank search page.<br />
Note: User preferences for the selected landing page negatively affect the performance improvement.<br />
Maximizing query yield<br />
Focus your query tuning effort on those queries providing the highest yield. The number of times a<br />
query executes multiplied by query execution time determines the yield.<br />
Figure 10, page 37 illustrates the possible yield of two queries. The first (fast) query executes 21 times<br />
and each instance takes 0.3 seconds to execute. The second (slow) query executes one time and takes<br />
1.8 seconds to execute. Because the fast query executes more frequently (21 times) than the slow<br />
query (1 time) a 10% improvement in the fast query execution time reclaims more CPU bandwidth<br />
(0.63 seconds) than a 10% improvement in the slow query execution time (0.18 seconds).<br />
Even though there can be more latitude for improving slow queries, the frequency with which the<br />
query gets executed often results in a larger aggregate impact. A small percentage improvement to<br />
frequently executed fast queries can provide a better yield than a large improvement to infrequently<br />
executed slow queries.<br />
36 <strong>EMC</strong> Documentum xCP 1.0 <strong>Performance</strong> <strong>Tuning</strong> <strong>Guide</strong>