Although there’s no “one size fits all” diagnostic method for all your performance issues, following is the general tuning approach recommended by Oracle to tackle complex middleware application performance problems.
5 Steps recommended by Oracle:
1. First, rule out all non-middleware infrastructure issues causing the performance problem.
2. Narrow down the scope of the problem by ascertaining the component experiencing the problem; for example, a specific WebLogic Server cluster, a specific WebLogic server, or the SOA infrastructure. The type of notification or alert that Cloud Control sends you should help identify the correct component.
3. Simultaneously, check the current findings, if any, from the Middleware Diagnostics Advisor.
4. Create a diagnostic snapshot to ensure that you’ve captured useful diagnostic information for analysis later on.
5. Once you identify the problem component, drill down to the relevant customized dashboard to get a high-level idea about the root cause. If, for example, you received an alert about slow messaging, check the WebLogic Server Home page and drill down from there to identify the root cause.
It’s a good practice to monitor diagnostics during peak load times and times of high resource (CPU, memory, and I/O) utilization.
To show how Cloud Control’s cross-tier monitoring capabilities help provide quick diagnosis and resolution of critical issues with extremely minimal overhead, let’s look at a typical example of performance troubleshooting with Cloud Control. As an example, let’s say you’ve received an alert about a performance issue related to a composite application that consists of several SOA and Java EE components. You notice that a specific JVM is experiencing locks from viewing the threads table for that JVM. You can drill down to the JVM Diagnostics page and check the key requests. You may notice a bunch of stuck threads and several threads in the database wait state, indicating a database problem, resulting in a hung application. You can then click on the Live Thread Analysis link to understand the thread behavior. To find the actual root cause, you click on the DB wait link to get to the actual database session that’s being blocked. And by clicking the Blocking ID, you can isolate the specific database session that’s blocking your application. The simple example described here points to the benefits of tying in JVM diagnostics with database diagnostics by Cloud Control.
Leave a Reply