Request Apportioning Device for Cooperative Cache Clusters

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In clustered application architectures, conventional cooperative caching methods become inefficient when there are many cache servers, leading to increased time in providing contents as they require excessive time to find a cache server with the requested content.

Innovation Solution

A request apportioning device collects and manages allocation history, server load, and threshold load information to strategically select a cache server for content transmission, implementing a cooperative caching process between servers with loads below specific thresholds to optimize content delivery.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If conventional cooperative caching method is used with many cache servers, then contents sharing cooperation is achieved, but time for finding cache server with contents increases significantly

Engineering Contradiction:
Improvecontents sharing cooperationVSAvoidtime for finding cache server
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The request apportioning device performs preliminary actions by collecting and managing allocation history information, server load information, and threshold load management information before content requests arrive. This pre-prepared data enables rapid decision-making when a cache server needs to find contents, eliminating the need for time-consuming real-time searches across many cache servers.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The request apportioning device acts as an intermediary between cache servers and content requests. It uses allocation history information to determine which cache server should handle a content request, avoiding the need for cache servers to directly search across the entire cluster. This mediator approach significantly reduces the time for finding cache servers with contents.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Productivity

If load balancing algorithm is used to distribute requests randomly, then load is balanced across cache servers, but contents provision time increases when many cache servers are present

Engineering Contradiction:
Improveload balancingVSAvoidcontents provision time
Core Design Contradiction:
ProductivityVSLoss of time

Solution Approach 1:

The system applies local quality by making load management decisions based on specific local conditions - allocation history information and current server load information - rather than using uniform random distribution. The request apportioning device selects cache servers based on their individual characteristics and current states, optimizing both load balancing and content provision time simultaneously.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The system implements feedback mechanisms by continuously monitoring server load information and allocation history, then using this information to make dynamic decisions about request routing. This feedback loop enables the system to adapt to changing conditions and optimize performance in real-time, reducing contents provision time while maintaining load balance.

Inventive Principle:
Principle #23Feedback

3Reliability

If cache servers inquire other cache servers for contents location, then cooperative caching is performed, but time consumption increases when many cache servers are in the cluster

Engineering Contradiction:
Improvecooperative cachingVSAvoidtime for inquiring cache servers
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The request apportioning device serves as an intermediary that manages the cooperative caching process. Instead of cache servers directly inquiring each other for contents location, the request apportioning device uses pre-collected allocation history information to determine the appropriate cache server, eliminating the time-consuming peer-to-peer inquiry process while maintaining cooperative caching functionality.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The request apportioning device performs preliminary collection and management of allocation history information before content requests arrive. This pre-prepared information enables rapid determination of which cache server should handle a request, eliminating the need for time-consuming real-time inquiries across many cache servers during the cooperative caching process.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS8959225B2Cooperative caching method and contents providing method using request apportioning device
Publication Date: 2015.02.17 STCLAB CO LTD
  • US8959225B2 patent drawing
  • US8959225B2 patent drawing
  • US8959225B2 patent drawing

AI summary

The present invention relates to a cooperative caching method and a contents providing method using a request apportioning device. While collecting and controlling allocation history information on respective cache servers in a cache cluster, server load information, and threshold load management information including an object service threshold load and a cooperative threshold load, the request apportioning device uses allocation history information and server load information to check a load level of a cache server (first cache server) having first contents from among the cache servers in the first cache cluster, and uses threshold load management information to determine whether there is a cache server that is less than the object service threshold load from among the first cache servers, and when the first cache server that is less than the object service threshold load is not found, it determines whether there is a cache server (second cache server) that is less than the cooperative threshold load from among the first cache servers, and when the second cache server is found, it selects a cache server (third cache server) from among the second cache servers. When the first cache server that is less than the object service threshold load is not found, the request apportioning device uses allocation history information and server load information to select a cache server (fourth cache server) that is less than the object service threshold load in the first cache cluster, allow cooperative caching for the contents A between the third cache server and the fourth cache server, and provide the contents A.