Automated Performance Monitoring for Software Applications

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing techniques for monitoring and analyzing performance of software applications are time-consuming, error-prone, costly, and inflexible, especially during agile development and post-release performance monitoring, requiring significant expertise and often disrupting the application's functionality.

Innovation Solution

A method and system for automatically monitoring and analyzing performance by executing statements on a target database, collecting performance metrics, comparing differences, and executing alarm actions when thresholds are exceeded, allowing for real-time identification and rectification of issues without requiring extensive expertise or disrupting the application.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If existing techniques are used to monitor and analyze performance of software applications, then performance monitoring is achieved, but the process is time-consuming and requires considerable manual effort

Engineering Contradiction:
Improveperformance monitoring accuracyVSAvoidtime consumption
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system enables self-service performance monitoring by automatically executing statements, collecting metrics, and analyzing performance without requiring manual developer intervention. The automated execution of performance monitoring statements and automatic comparison of metrics eliminates the need for developers to manually analyze source code and database statistics.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The system performs preliminary performance monitoring and analysis during the development phase itself, rather than waiting until post-release. By executing performance statements and analyzing metrics before deployment, the system identifies issues early when they are easier and less costly to fix.

Inventive Principle:
Principle #10Preliminary action

2Measurement precision

If manual analysis of database statistics is performed, then performance insights are obtained, but the process is error-prone and expensive

Engineering Contradiction:
Improveperformance analysis accuracyVSAvoidanalytical tool complexity
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The system replaces manual mechanical analysis with automated computational analysis. Instead of developers manually examining database statistics and source code, the system automatically executes performance statements, collects metrics, and performs comparative analysis using predefined thresholds and algorithms.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

Solution Approach 2:

The system creates copies of performance data through multiple execution instances and compares these copies to identify performance degradation. By executing statements multiple times and comparing the resulting metrics, the system detects changes in performance without requiring complex analytical tools.

Inventive Principle:
Principle #26Copying

3Reliability

If post-release performance monitoring is conducted, then performance issues are identified, but corrective actions are costly and may disrupt application functionality

Engineering Contradiction:
Improveperformance issue detectionVSAvoidcost of corrective actions
Core Design Contradiction:
ReliabilityVSEase of manufacture

Solution Approach 1:

The system performs preliminary performance monitoring during the development phase, identifying and addressing performance issues before the application is released. This early detection prevents costly post-release corrective actions and avoids disruptions to production applications.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system cushions against post-release performance problems by proactively monitoring and analyzing performance during development. By detecting and addressing issues beforehand, the system prevents the need for expensive emergency fixes and minimizes the risk of performance degradation in production.

Inventive Principle:
Principle #11Beforehand cushioning (Prior cushioning)

4Reliability

If existing performance monitoring techniques are used, then performance analysis is achieved, but flexibility in integrating with test automation tools is limited

Engineering Contradiction:
Improveperformance monitoring capabilityVSAvoidintegration flexibility
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The system achieves universality by designing performance monitoring statements that can be executed in multiple contexts and integrated with various test automation tools. The standardized statement execution and metric collection mechanisms work across different development environments and testing frameworks.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The system provides dynamic adaptability by allowing flexible configuration of performance statements, metrics, and thresholds. The system can adapt to different use cases and integration scenarios through configurable parameters and customizable performance monitoring approaches.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentUS11874760B2Method and system for managing performance for use cases in software applications
Publication Date: 2024.01.16 LARMIK OY
  • US11874760B2 patent drawing
  • US11874760B2 patent drawing
  • US11874760B2 patent drawing

AI summary

A method for managing a performance for at least one use case in a software application. The method includes: executing, for a first instance, a plurality of statements pertaining to a given use case on a target database, the plurality of statements being a part of the software application; collecting first performance metrics pertaining to the first instance of execution of the given use case; executing, for a second instance, the plurality of statements on the target database; collecting second performance metrics pertaining to the second instance of execution of the given use case; comparing the first performance metrics and the second performance metrics to determine difference therebetween; and executing at least one alarm action when the difference is greater than a predefined threshold.