Browse Prior Art Database

Low overhead tracing via lazy generation Disclosure Number: IPCOM000238235D
Publication Date: 2014-Aug-12
Document File: 3 page(s) / 34K

Publishing Venue

The Prior Art Database


The use of tracing to carry out performance analysis and monitoring of a software application is common, and multiple approaches to reducing the performance overhead of implementing the data collection have been tried. Outlined below is an approach that makes data available, but defers the cost of collection until it is decided that there is a need to make the data available.

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

Page 01 of 3

Low overhead tracing via lazy generation

The use of tracing and/or instrumentation of source code with trace statements is probably the most common form of collecting data to carry out debugging, performance analysis and monitoring of a software application. As a result, multiple techniques have been implemented to reduce the volume of data and performance overhead of the data collection.

    One such approach is sampling, where tracing is only enabled periodically. In the most basic form, this takes the form of tracing a method execution, or an entire task/activity flow (eg. transaction request) on a 1 in x basis. This is effective in reducing the volume of data generated and the performance overhead, and creates a representative set of data over time that shows the general behaviour of the instrumented code. The use of sampling does however have a major limitation when trying to capture data for intermittent events where the sample event is unlikely to align with the intermittent event.

    Given the value of sampling for the reduction of trace volume and performance cost, but the limitation that samples are unlikely to align to intermitted events, there is an advantage to a system that can generate samples when interesting intermittent events occur.

    The challenge is that it is often not possible to know that a interesting event has occurred until after the event has started. For example, we cannot know that a transaction request has returned and error, or failed to return within an expected time, until the request completes.

    What is therefore proposed is an approach that ensures the data required to be able to generate a trace sample is retained until its possible to determine whether a trace sample needs to be generated. This can be done by maintaining references to the data required to create a trace sample, ensuring that the data is still available at the end of the event, and then lazily creating the sample trace records as a post processing event only if there is interest in that event.

    Below is a diagram showing how the proposed approach would work for the tracing of a HTTP Request in an Application Server:

Page 02 of 3

    At each stage in the request flow, context data for each step is retained by adding a reference to the existing context objects into the RequestContext object store. This can be implemented as ThreadLocal data, therefore being accessible by any methods executing on the thread and avoids needing to be passed from method to method. As this is only holding references to existing data, no data creation or transform occurs, meaning there is virtually no performance cost. For example, the Servlet Container is called with the following API:

HttpServlet.service(HttpServletRequest req, HttpServletResponse resp)

    Here the a reference to the HttpServletRequest object can be stored in the RequestContext. The HttpServletRequest object subsequently provides access to the URL, date/time and query etc for the request.

    There are s...