Browse Prior Art Database

Selective tracing based on performance goals/restrictions

IP.com Disclosure Number: IPCOM000235470D
Publication Date: 2014-Mar-03
Document File: 2 page(s) / 40K

Publishing Venue

The IP.com Prior Art Database

Abstract

The idea of this disclosure is to allow restrictions to be placed on the performance impact of trace. System performance will be monitored, and when trace is enabled, if the performance impact is too severe, then the requested trace specification will only be applied to a subset of requests. The number of requests that trace is enabled for will be dynamically changed, based on the system performance to ensure the performance impact does not exceed the restrictions specified by the user.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 2

Selective tracing based on performance goals/restrictions

Trace is essential for any middleware/application, and is useful for both debugging problems, and also for understanding what is happening within the server. However enabling trace can have a huge performance impact, which often makes it

impractical to enable on production systems, and it can also slow down processing so much that it hides problems that are caused by timing issues. This can often make debugging problems on a production server very time consuming, which can

adversely affect customer satisfaction.

    The well established and usual method for reducing the amount of trace, and so reduce the performance impact is to only enable trace on a subset of components/classes. However this has a number of drawbacks:


1. Only tracing a subset of classes is often not sufficient to understand the full flow through the system, and often issues are caused not just by a problem in a single class or component, but how they interact.


2. Even with trace enabled for a small number of classes the performance impact can still be unacceptable.

    The idea of this disclosure is to allow restrictions to be placed on the performance impact of trace. System performance will be monitored, and when trace is enabled, if the performance impact is too severe, then the requested trace specification will only be applied to a subset of requests. The number of requests that trace is enabled for will be dynamically changed, based on the system performance to ensure the performance impact does not exceed the restrictions specified by the user.

    The benefits of this approach are that trace can be enabled with an acceptable performance impact. This should make it much more feasible to enable trace on a high performance production system, and aid the debugging of issues. As trace will not be enabled for all requests it does mean that the trace may not be enabled for a request that hits a problem, but as the performance impact is acceptable, trace can be enabled for a longer time, so the issue could eventually be created on a request that had trace enabled.

    The trace specification is controlled in the usual way, by specifying a list of components, or packages or classes that are required to be traced.
e.g. com.ibm.wbe.*=fi...