RMA is typically slow and recently we were asked to make it faster and explaining the WDK stack is not why we were brought in. The application consisted of custom everything (menu items, functionality, workflows, lifecycles, alias sets, object types, complex security model, yada yada yada) that extended RMA. The environment is Documentum 6.5 SP2 on Solaris with Oracle and Web Logic is the Application server.

We started by reviewing the application’s design and certain use cases that manifested the performance issues.
Here is a collection of what we did that would either confirm our suspicions or give us another starting point:

1. ALWAYS start with a Documentum DFC trace (back to basics)
2. Run the trace file through the awk scripts provided by EMC (we don’t like reading through 500K lines in a log file).
3. Ignore the log chatter and focus on events that took longer than 2 seconds (read above)
4. Start SQL Trace (iapi for the session)
5. Review Oracle’s AWS report.

We were mostly right is our thinking. The performance issues manifested when making updates to
objects (well…updating 4 or more attributes on thousands of objects) and workflow invocation issues.
Re-writing the application was not an option nor was the design itself deficient; it just mimicked the user
process.

So we did the following:

• Increased the number of Method Server threads (we never know when an Admin will schedule a job and why)
• Increased the number of wf_agent_worker_threads ( we saw in the trace file that there were more workflows being created than worker threads)
• Decreased the wf_sleep_interval ( seconds matter)
• Increased the method server memory Xms512m –Xmx512m (heavy duty methods)
• Created Indexes on some attributes of the custom type
• Changed some queries to direct them against the indexed attributes
• Changed the CBO from ALL_ROWS to FIRST_ROWS _10 (saved micro seconds)
• Changed the optimizeri ndex cost adj to 5 and the optimizer index caching to 95 (almost default EMC recommendations).

We were able to save about 10 seconds on select queries, about 5 seconds on the update queries, and the workflows always got invoked.
It helps to remember that we are dealing with multi-tiered application and performance tuning is an ongoing process, but the seconds saved do add up and every second helps with user adoption.
Java and Oracle tuning are sciences amongst themselves. The idea here is to give a starting point on your journey into performance tuning. Some do find the journey enjoyable 🙂

Dinesh S, Karthik K and Chris S