Server Application Performance Data Collection via Selective Instrumentation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Troubleshooting performance issues in multi-tiered server applications deployed in production environments is challenging due to the difficulty in reproducing issues in test environments and the high overhead of existing data collection methods, which often miss critical data points and impose significant performance burdens.

Innovation Solution

A system and method that combines selective code instrumentation and stack trace sampling to collect application performance data, minimizing overhead by instrumenting only selected functions and sampling threads with timestamps older than a predetermined period, and integrating the data to form a unified performance report.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If comprehensive data collection techniques are used to capture all server request execution details, then measurement precision and reliability are improved, but performance overhead increases significantly

Engineering Contradiction:
Improvedata qualityVSAvoidperformance overhead
Core Design Contradiction:
Measurement precisionVSProductivity

Solution Approach 1:

The patent implements partial action by selectively instrumenting only certain functions and sampling threads based on timestamp criteria rather than collecting data from all functions and threads. This selective approach captures sufficient performance data to identify long-running requests while minimizing the performance overhead associated with comprehensive data collection.

Inventive Principle:
Principle #16Partial or excessive action

Solution Approach 2:

The patent changes the parameter of data collection intensity by introducing timestamp-based sampling that adapts the level of instrumentation. Threads with older timestamps are sampled at different rates, allowing the system to adjust measurement precision dynamically based on the age of the thread, thereby balancing data quality with performance overhead.

Inventive Principle:
Principle #35Parameter changes

2Loss of information

If data collection is performed for all server requests, then measurement completeness is improved, but performance overhead increases

Engineering Contradiction:
Improvedata completenessVSAvoidperformance overhead
Core Design Contradiction:
Loss of informationVSProductivity

Solution Approach 1:

The system performs partial data collection by instrumenting selected functions and sampling specific threads rather than all server requests. This approach maintains data completeness for identifying performance issues while reducing the overall performance overhead by excluding non-critical requests from intensive monitoring.

Inventive Principle:
Principle #16Partial or excessive action

Solution Approach 2:

The patent extracts only the necessary data elements needed for performance analysis—specifically focusing on threads with older timestamps and selected functions—rather than collecting all possible data from every server request. This extraction approach ensures critical performance data is captured while minimizing unnecessary data collection overhead.

Inventive Principle:
Principle #2Taking out (Extraction)

3Productivity

If selective instrumentation is used to reduce overhead, then performance overhead is reduced, but measurement precision may be insufficient to capture critical performance issues

Engineering Contradiction:
Improveperformance overheadVSAvoiddata quality
Core Design Contradiction:
ProductivityVSMeasurement precision

Solution Approach 1:

The patent uses parameter changes by implementing timestamp-based sampling that adjusts measurement precision dynamically. Threads with older timestamps are subjected to sampling at different rates, allowing the system to maintain high measurement precision for potentially problematic long-running requests while keeping overhead low for shorter-lived requests.

Inventive Principle:
Principle #35Parameter changes

Solution Approach 2:

The system applies partial instrumentation to selected functions and threads rather than all code paths. This selective approach is enhanced by timestamp-based sampling that ensures sufficient measurement precision is maintained for threads that are more likely to exhibit performance issues, while reducing instrumentation overhead elsewhere.

Inventive Principle:
Principle #16Partial or excessive action

4Productivity

If random sampling is used to reduce overhead, then performance overhead is reduced, but reliability decreases due to missing critical data points

Engineering Contradiction:
Improveperformance overheadVSAvoiddetection reliability
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The patent replaces random sampling with timestamp-based sampling, changing the sampling parameter from random selection to time-based selection. This approach improves detection reliability by systematically sampling threads that have been running longer and are more likely to exhibit performance issues, rather than relying on random selection that may miss critical data points.

Inventive Principle:
Principle #35Parameter changes

Solution Approach 2:

The system performs preliminary action by instrumenting selected functions and establishing timestamp tracking before performance issues manifest. This preliminary instrumentation ensures that when sampling occurs, the data collection is targeted at threads that are most likely to reveal performance problems, thereby improving detection reliability compared to random sampling.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentEP2438523B1System and method for collecting application performance data
Publication Date: 2018.08.01 MICRO FOCUS LLC
  • EP2438523B1 patent drawingFigure 1
  • EP2438523B1 patent drawingFigure 2
  • EP2438523B1 patent drawingFigure 3

AI summary

Systems and methods are provided for collecting application performance data. The system (100) includes a server (110) for hosting a server-side application (120). An instrumentation module (130) is included on the server. The instrumentation module can selectively instrument functions (125) of the server-side application to obtain instrumented function operation data. The instrumentation module can also maintain an instrumented function call stack (190) for each application thread. A sampling module (140) is included on the server. The sampling module can sample application threads of the server-side application to obtain sampled function operation data. The sampling module can sample application threads based on at least one of an age of a timestamp obtained through instrumentation and a determination of which threads are executing server requests based on emptiness of the stack.