Request Processing with Distress Gradients for Server Load Management

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In cloud-based stateless server architectures, servers lack awareness of previous requests from the same client, leading to inefficiencies and potential service disruptions during high loads, as they cannot prioritize or adjust processing based on previous request failures.

Innovation Solution

A method where a user terminal monitors response times for requests and appends distress information to subsequent requests, allowing servers to prioritize and potentially switch to lower complexity algorithms, enabling configurable quality and time-to-serve trade-offs by signaling failure information through distress gradients.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If servers process all requests with full complexity algorithms, then service quality is maintained, but processing time increases and server load increases during high traffic periods

Engineering Contradiction:
Improveservice qualityVSAvoidprocessing time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system dynamically adjusts the complexity of processing algorithms based on real-time conditions. When distress information indicates server overload or high traffic, the system switches from full complexity algorithms to lower complexity algorithms, enabling adaptive response to changing system states and balancing quality with processing speed.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The invention changes the processing parameters by introducing distress information that triggers different processing modes. The server can modify its behavior by adjusting the complexity level of algorithms based on the distress gradient, allowing flexible parameter adjustment to optimize both quality and time-to-serve under different load conditions.

Inventive Principle:
Principle #35Parameter changes

2Reliability

If servers process all requests with full complexity algorithms, then service quality is maintained, but server load increases during high traffic periods

Engineering Contradiction:
Improveservice qualityVSAvoidserver load
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The system dynamically adjusts processing complexity based on server load conditions indicated by distress information. During high traffic periods, the server transitions to lower complexity algorithms, reducing the computational burden and allowing the system to handle higher volumes of requests without overwhelming server resources.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The server changes operational parameters by selecting different algorithm complexity levels based on distress information. This allows the system to maintain service quality when possible but reduce processing complexity when server load becomes excessive, effectively managing productivity under varying conditions.

Inventive Principle:
Principle #35Parameter changes

3Device complexity

If servers are stateless and do not track previous requests, then system simplicity is maintained, but ability to prioritize requests based on failure history is lost

Engineering Contradiction:
Improvesystem simplicityVSAvoidrequest prioritization capability
Core Design Contradiction:
Device complexityVSAdaptability or versatility

Solution Approach 1:

The invention introduces distress information as an intermediary mechanism that carries failure history from the client to the server without requiring the server to maintain state. The distress gradient acts as a mediator that conveys prioritization needs based on previous failures, enabling adaptability while preserving server statelessness and system simplicity.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The system implements feedback through distress information that communicates the client's experience with previous request failures. This feedback loop allows the server to adjust its behavior and prioritize requests based on historical performance without requiring complex state tracking, maintaining simplicity while gaining adaptability.

Inventive Principle:
Principle #23Feedback

Data Source

PatentEP2868069B1Processing requests
Publication Date: 2020.08.19 MICROSOFT TECHNOLOGY LICENSING LLC
  • EP2868069B1 patent drawingFigure 1
  • EP2868069B1 patent drawingFigure 2
  • EP2868069B1 patent drawingFigure 3~4

AI summary

Requests are processed at a computer server by receiving a request for service from a user terminal, the request including distress information representing a degree of failure to process at least one prior similar request from the user terminal for the service. The distress information is received from the request and the request is processed in accordance with the distress information. A user terminal provides distress information in a request, based on responses received from the server.