Dynamic Transaction Timeout Adjustment for Server Efficiency

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing transaction processing systems require static timeout parameters, leading to inefficiencies and excessive resource allocation due to variable transaction loads, as they often result in either excessive timeouts or overprovisioning of servers to handle peak loads, which is costly and inefficient.

Innovation Solution

A transaction server system that dynamically adjusts the transaction timeout parameter based on real-time monitoring of transaction request timeouts, allowing the parameter to be adjusted without restarting the application, by shortening the timeout period during high timeout burdens and lengthening it during low burdens, thereby optimizing resource usage and reducing the need for overprovisioning.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If static timeout parameters are used in transaction processing systems, then system simplicity is maintained, but transaction efficiency deteriorates due to excessive timeouts and overprovisioning during variable loads

Engineering Contradiction:
Improvetransaction efficiencyVSAvoidsystem complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The timeout parameter is transformed from a static configuration value to a dynamic one that automatically adjusts based on real-time transaction load conditions. The system monitors transaction volumes and timeout rates, then modifies the timeout parameter accordingly - increasing it during high load periods to prevent excessive timeouts, and decreasing it during low load periods to maintain responsiveness. This dynamic adaptation resolves the contradiction by allowing the system to optimize transaction efficiency without requiring complex manual configuration or overprovisioning.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system implements a feedback mechanism that continuously monitors transaction processing metrics including timeout rates and transaction volumes. Based on this feedback, the timeout parameter is automatically adjusted - when timeout rates exceed a threshold, the parameter is increased; when timeout rates are low, it is decreased. This closed-loop control system resolves the contradiction by using real-time performance data to optimize the timeout parameter, improving transaction efficiency without adding significant system complexity.

Inventive Principle:
Principle #23Feedback

2Reliability

If timeout parameter is increased to reduce timeouts during peak loads, then transaction reliability improves, but resource allocation efficiency deteriorates due to overprovisioning

Engineering Contradiction:
Improvetransaction reliabilityVSAvoidresource allocation efficiency
Core Design Contradiction:
ReliabilityVSLoss of energy

Solution Approach 1:

The timeout parameter dynamically adapts to transaction load conditions rather than maintaining a fixed high value. During peak loads, the parameter increases to maintain transaction reliability by reducing timeouts. During off-peak periods, it automatically decreases to improve resource allocation efficiency by allowing faster timeout of non-critical transactions. This dynamic behavior resolves the contradiction by ensuring high reliability only when necessary, rather than continuously overprovisioning resources.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system changes the timeout parameter value based on monitored transaction conditions. When transaction volumes exceed thresholds or timeout rates indicate stress, the parameter is increased to improve reliability. When conditions normalize, the parameter is decreased to optimize resource usage. This parameter adjustment strategy resolves the contradiction by matching resource allocation to actual demand, maintaining reliability during critical periods while improving efficiency during normal operations.

Inventive Principle:
Principle #35Parameter changes

3Speed

If timeout parameter is decreased to improve responsiveness during low loads, then system responsiveness improves, but transaction reliability deteriorates due to excessive timeouts during high loads

Engineering Contradiction:
Improvesystem responsivenessVSAvoidtransaction reliability
Core Design Contradiction:
SpeedVSReliability

Solution Approach 1:

The timeout parameter becomes dynamic, automatically decreasing during low transaction loads to improve system responsiveness and increasing during high loads to maintain transaction reliability. The system monitors load conditions and adjusts the parameter accordingly, resolving the contradiction by allowing the timeout behavior to adapt to current operational context rather than remaining fixed at a suboptimal value.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The timeout parameter value is changed based on monitored transaction conditions. During low loads, the parameter is decreased to improve responsiveness by enabling faster timeout of pending transactions. During high loads, it is increased to prevent excessive timeouts and maintain reliability. This conditional parameter adjustment resolves the contradiction by optimizing the timeout behavior for current system state rather than using a single fixed value that cannot satisfy both requirements simultaneously.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS8966487B1Application transaction wait time dynamic adjustment
Publication Date: 2015.02.24 T MOBILE INNOVATIONS LLC
  • US8966487B1 patent drawing
  • US8966487B1 patent drawing
  • US8966487B1 patent drawing

AI summary

A transaction server. The transaction server comprises a processor, a non-transitory memory, and an application stored in the non-transitory memory. When executed by the processor, the application transmits a plurality of transaction requests to at least one backend server, where the backend server performs processing on the transaction, determines that a transaction request timeout occurs when a transaction response has not been received from the at least one backend server within a timeout time period after transmitting the associated transaction request, and adjusts the timeout time period based on the transaction request timeouts without restarting.