Home > Weblogic, WLDF > Instrumenting Weblogic Applications with WLDF: Where Does The Application Spend Time?

Instrumenting Weblogic Applications with WLDF: Where Does The Application Spend Time?

February 1, 2012 Leave a comment Go to comments

The WebLogic Diagnostic Framework is a very powerful tool complementing the WebLogic server that offers virtually unlimited possibilities to monitor, tune and troubleshoot your deployed applications. In this post I will describe how to use WLDF in order to get a better idea on where does an application spend it’s time, broken down by components. This is achieved by using the WLDF application-scoped instrumentation. The main steps for setting it up are:

  1. Enable the Diagnostic Context to track down a request throughout the system;
  2. Enable server-scoped instrumentation;
  3. Enable application-scoped instrumentation;
  4. Define specific Diagnostic Monitors and assign them specific Actions;
  5. Update the application with the new settings;
  6. Access the instrumented application and analyze the collected data;

Let’s get into details with each of these steps…

1. Enable the Diagnostic Context

When the Diagnostic Context is enabled for a certain server, Weblogic will assign an Execution Context ID (ECID) to each request. The ECID will then be used to track down the request throughout various subsystems in the application server. To enable the Diagnostic Context:

  • Expand the “Diagnostics” menu in the “Domain Structure” section of the Administration Console, and click “Context”.
  • Click “Lock and Edit”
  • Select the desired server and click “Enable”
  • “Save” and “Activate Changes”

2. Enable server-scoped instrumentation

In order to use application-scoped instrumentation, a higher level server-scoped instrumentation must be enabled. The advantage is that if you have different instrumentation settings for many different applications, you can easily disable all instrumentation in one step by disabling the server-scoped instrumentation. The action is also performed in the Administration console:

  • Click on „Diagnostic Modules” and click „New” to create a new Diagnostic Module. Give it a Name and optionally, a description:

  • Click „OK”, then click on the newly created Module to configure it. You must first target it to the server(s) to be instrumented:

  • Click on the “Configuration” tab and Enable the server-scoped instrumentation:

3. Enable application-scoped instrumentation;

In the same way the server-scoped instrumentation was enabled, the application-scoped instrumentation must be enabled also. To do this:

  • Enable the application-scoped instrumentation. Click on the desired deployment, then navigate to the “Configuration” tab and the “Instrumentation” sub-tab.

  • On the same page, you can add specific monitors and assign actions to each of them. Click on „Add Monitor From Library”:

4. Define specific Diagnostic Monitors and assign them specific Actions

This is the step where we actually define what information we want to get from the deployment instrumentation

  • In the next screen you can choose a list of already defined monitors, which basically mark the time before, after and around certain events in the application, around being the difference between after and before.

You can find a specific monitor for your use case in the reference below:

Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 11g

To check where my sample application is spending the time, I have chosen a series of „Around” monitors shown in the picture above.  Click „Ok” once you have a definite list of monitors you are interested in.

  • This application setting will be specified in a Deployment Plan, so pressing Ok will take you to the „Deployment Plan Assistant” screen where you must specify a name and location for your deployment plan.

  • Once saved, go back to the „Configuration” -> „Instrumentation” screen and click each Diagnostic Monitor to assign an action to it.
  • Click on „Servlet_Around_Service” for example will show the following available actions:

  • Select the „TraceElapsedTimeAction” and then click „Save”

Optionally, if you do not want all the requests to be instrumented, you can enable „Dye Filtering” and make sure that only a subset of requests are being instrumented based on a certain criteria. In the example below, only requests coming from the mentioned IP address will be instrumented. This can be useful in a production environment, where you will want to keep the overhead of instrumenting an application to a minimum

  • Repeat these steps for each Diagnostic Modules and make sure the TraceElapsedTimeAction is assigned to each one:

5. Update the application with the new settings

I mentioned before that a Deployment plan was created in order to enable the instrumentation at application level. Besides the deployment plan, a new descriptor is created, weblogic-diagnostics.xml that contains the setting for the Diagnostic modules. Consequently, the application must be updated to take into consideration these new settings:

  • Navigate to the “Deployments” screen and click “Lock and Edit”
  • Select the deployment and click “Update”
  • Select “Redeploy this application using the following deployment files”

Click „Next” for a review screen, or „Finish” to update the application in one step.

6. Access the instrumented application and analyze the collected data

Only thing to do now is to access the application, perform some of the usual activities and then analyze the collected data. Once there is some work being done in the application, expand the “Diagnostics” menu in the Administration console and open the  “Request Performance” screen.

Select the specific server instance and a timeframe that will cover the work performed in the application. Clicking “Refresh” should then reveal the requests:

Notice the bar in front of each ECID (a request), a module (application) and timestamp. The longer the bar, the longer the response time. You can see details of each request by clicking it:

This will show the total time of the request, but also the time broken down by methods, invocation counts for each method, a total and an average time.

All this information can also be accessed in the EventsData.

Hopefully this procedure will help you identify bottlenecks in the application and lead you towards a productive performance tuning effort.

As always, any questions or comments are highly appreciated.

  1. fan
    February 18, 2012 at 11:09 pm

    very nice. I love it. and very useful. Thank you Radu for this

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: