Application Server QoS Admission Control via Transaction Queuing

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current server systems struggle to meet quality of service (QoS) requirements for multiple applications running concurrently, as existing QoS methodologies primarily focus on network bandwidth allocation and fail to provide guarantees at the application level, especially when different types of traffic compete for resources.

Innovation Solution

A queuing system with priority of service is employed to dynamically determine whether to accept or reject new transactions based on estimated average response times and throughput rates, ensuring that QoS requirements are met by calculating and comparing average waiting times against required thresholds.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If multiple applications are concurrently running on the same server with different QoS requirements, then the server can provide diverse services to multiple clients, but it becomes difficult to meet the QoS requirements for each application

Engineering Contradiction:
Improveservice diversityVSAvoidQoS guarantee
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The patent segments the server system into multiple queues, with each queue dedicated to a specific application or transaction type. This segmentation allows the server to manage different QoS requirements independently for each application while maintaining overall system versatility. The server can allocate resources to each queue based on its specific QoS needs without interference from other applications.

Inventive Principle:
Principle #1Segmentation

2Productivity

If the server accepts all incoming transactions, then the throughput rate is maximized, but the response time may exceed acceptable ranges and violate QoS requirements

Engineering Contradiction:
Improvethroughput rateVSAvoidresponse time
Core Design Contradiction:
ProductivityVSLoss of time

Solution Approach 1:

The patent implements dynamic transaction admission control that adjusts the acceptance criteria for incoming transactions based on current system conditions. The server continuously monitors queue lengths, response times, and throughput rates, and dynamically modifies which transactions are accepted or rejected. This dynamic approach allows the server to maintain high throughput when conditions permit while ensuring QoS requirements are met when system load increases.

Inventive Principle:
Principle #15Dynamics

3Reliability

If the server prioritizes transactions with shorter response times, then QoS requirements are met, but the complexity of transaction management increases

Engineering Contradiction:
ImproveQoS requirement fulfillmentVSAvoidtransaction management complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent changes the management parameter from individual transaction prioritization to queue-based admission control. Instead of complex real-time prioritization of individual transactions, the system uses simpler parameters such as queue length thresholds and average response time metrics for each application queue. This parameter change reduces management complexity while maintaining QoS guarantees through controlled admission rather than complex scheduling.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS7496653B2Method, system, and computer program product for providing quality of service guarantees for clients of application servers
Publication Date: 2009.02.24 SAP SE
  • US7496653B2 patent drawing
  • US7496653B2 patent drawing
  • US7496653B2 patent drawing

AI summary

The present invention provides a method, system, and computer program product for providing quality of service guarantees at the application level for clients of application servers. The method includes: receiving a request for a transaction of type k; calculating a throughput rate λi of each type of transaction i, 1≦i≦n, in response to the request for the transaction of type k; calculating an average residual time Ri of each type of transaction i, 1≦i≦n; calculating an average residual time R of a transaction in service; calculating an average waiting time Wk of a transaction of type k; comparing the average waiting time Wk of a transaction of type k to a required average waiting time W{tilde over (k)} of a transaction of type k; and selectively accepting the request for the transaction of type k, based on a result of the comparing step.