WO2023055364A1

WO2023055364A1 - System, method and computer-readable medium for determining a cache ttl

Info

Publication number: WO2023055364A1
Application number: PCT/US2021/052777
Authority: WO
Inventors: Ka Chon LOI; Shao Yuan Wu; Ming-Che Cheng
Original assignee: 17Live Japan Inc.; 17Live (Usa) Corp.
Priority date: 2021-09-30
Filing date: 2021-09-30
Publication date: 2023-04-06
Also published as: JP7426020B2; JP2023548722A

Abstract

The present disclosure relates to a system, a method and a computer-readable medium for determining a time to live (TTL) for a data object on a cache server. The method includes detecting an update frequency of the data object, detecting a number of users accessing the data object, and determining the TTL based on the update frequency and the number of users. The present disclosure can provide the latest data object to users and protect the backend server from being overburdened.

Description

SYSTEM, METHOD AND COMPUTER-READABLE MEDIUM FOR DETERMINING A CACHE TTL

Field of the Invention

[0001] The present disclosure relates to the storage of information on an Internet and, more particularly, to the storage of data objects on a cache of the Internet.

Description of the Prior Art

[0002] Caches or caching techniques are applied and leveraged throughout technologies including operating systems, networking layers including content delivery networks (CDN), domain name systems (DNS), web applications, and databases. One can use caching to reduce latency and improve input/output operations per second (IOPS) for many read-heavy application workloads, such as Q&A portals, gaming, media sharing, content streaming, and social networking. Cached information can include the results of database queries, computationally intensive calculations, application programming interface (API) requests/responses and web artifacts such as HTML, JavaScript, and image files.

[0003] Caching is crucial for CDN services. A CDN moves the content/ data object or a copy of the content/ data object on a website server or a backend server, such as a backend server of an application, to proxy servers or cache servers, where the content can be quickly accessed by website visitors or users of the application accessing from a nearby location.

[0004] Time to live (TTL) is the time that a content/ data object (or a copy of the content/ data object) is stored in a caching system such as a cache server before it's deleted or refreshed. In the context of CDNs, TTL typically refers to content caching, which is the process of storing a copy of the resources on a website or an application server (e.g., images, prices, text, streaming content) on CDN cache servers to improve page load speed and reduce the bandwidth consumption and workloads on the origin server.

Summary of the Invention

[0005] A method according to one embodiment of the present disclosure is a method for determining a time to live (TTL) for a data object on a cache server being executed by one or a

1

SUBSTITUTE SHEET (RULE 26) plurality of computers, and includes: detecting an update frequency of the data object, detecting a number of users accessing the data object, and determining the TTL based on the update frequency and the number of users.

[0006] A system according to one embodiment of the present disclosure is a system for determining a TTL for a data object on a cache server that includes one or a plurality of processors, and the one or plurality of computer processors execute a machine-readable instruction to perform: detecting an update frequency of the data object, detecting a number of users accessing the data object, and determining the TTL based on the update frequency and the number of users.

[0007] A computer-readable medium according to one embodiment of the present disclosure is a non-transitory computer-readable medium including a program for determining a TTL for a data object on a cache server, and the program causes one or a plurality of computers to execute: detecting an update frequency of the data object, detecting a number of users accessing the data object, and determining the TTL based on the update frequency and the number of users.

Brief description of the drawings

[0008] FIG. 1 shows a schematic configuration of a communication system according to some embodiments of the present disclosure.

[0009] FIG. 2 shows an exemplary functional configuration of a communication system according to some embodiments of the present disclosure.

[0010] FIG. 3 shows an exemplary sequence chart illustrating an operation of a communication system in accordance with some embodiments of the present disclosure.

[0011] FIG. 4 shows a flowchart illustrating a process in accordance with some embodiments of the present disclosure.

Detailed Description

[0012] A TTL of a data object governs the refresh rate of the data object (or a copy of the data object) on a cache server, ideally ensuring that "stale" versions of the data object aren't served to visitors visiting the application or the website wherein the data object can be accessed. A TTL directly impacts a page load time of an application or a website (i.e., cached data loads faster), as well as content freshness (i.e., data cached for too long can become stale).

2

SUBSTITUTE SHEET (RULE 26) [0013] Static files or data objects (e.g., image files, PDFs, etc.) are rarely updated, and therefore usually have a longer TTL. For example, an ecommerce site's collection of product images represents static content. Because they're rarely refreshed, it's safe to cache them for an extended period (e.g., days or weeks). This makes setting their TTL predictable and easy to maintain.

[0014] Conversely, dynamic contents or data objects (e.g. HTML files) are constantly updated, complicating the setting of accurate TTLs. For example, a comment section under a product is considered dynamic, as it changes frequently. If the TTL is set too long, then the comments cannot be reflected in time.

[0015] Another concern point of the TTL setting is the number of users accessing the data object. If a TTL is set too short while there are still a lot of users trying to access the corresponding data object, there would be a risk that, when the TTL ends, many of the users would need to access the origin server for the data object (which may be done by directly accessing the origin server or by accessing the origin server through the cache server) because they could not get the response at the cache server. When the origin server is accessed by a number of users that exceeds a maximum capacity the origin server can support, which usually results in an overwhelmed or overburdened number of query per second (Q.PS) for the origin server, there may be a crashdown of the server or, some of the users can't achieve the data access successfully.

[0016] Therefore, how to determine the TTL on a cache server for a data object based on factors such as the update frequency of the data object or the number of users accessing the data object is crucial as to providing the freshest data, preventing access fails for the users, or protecting the origin server from being out of function. In some embodiments, a data object can be referred to as a resource or a resource data.

[0017] FIG. 1 shows a schematic configuration of a communication system 1 according to some embodiments of the present disclosure. The communication system 1 may provide a live streaming service with interaction via a content. Here, the term "content" refers to a digital content that can be played on a computer device. In other words, the communication system 1 enables a user to participate in real-time interaction with other users on-line. The communication system 1 includes a plurality of user terminals 10, a backend server 30, and a streaming server 40. The user terminals 10, the backend server 30 and the streaming server 40 are connected via a network 90, which may be the Internet, for example. The backend server 30 may be a server for synchronizing interaction between the user terminals and/ or the streaming server 40. In some embodiments, the backend server 30 may be referred to as the origin server of an application (APP) provider. The streaming

3

SUBSTITUTE SHEET (RULE 26) server 40 is a server for handling or providing streaming data or video data. In some embodiments, the backend server 30 and the streaming server 40 may be independent servers. In some embodiments, the backend server 30 and the streaming server 40 may be integrated into one server. In some embodiments, the user terminals 10 are client devices for the live streaming. In some embodiments, the user terminal 10 may be referred to as viewer, streamer, anchor, podcaster, audience, listener or the like. Each of the user terminal 10, the backend server 30, and the streaming server 40 is an example of an information-processing device. In some embodiments, the streaming may be live streaming or video replay. In some embodiments, the streaming may be audio streaming and/or video streaming. In some embodiments, the streaming may include contents such as online shopping, talk shows, talent shows, entertainment events, sports events, music videos, movies, comedy, concerts or the like.

[0018] FIG. 2 shows an exemplary functional configuration of the communication system 1. In FIG. 2, the network 90 is omitted and a CDN server 50 is shown to connect the user terminals 10 and the backend server 30. The CDN server 50 could be part of the network 90. In some embodiments, the CDN server 50 may function as a cache server.

[0019] In this embodiment, the user terminal 10 includes a Ul unit 11, a decoder 12, a renderer 13, and a display 13. The user terminal 10 may access the backend server 30 and the streaming server 40 for their data objects through the CDN server 50 by, for example, sending API requests and receiving API responses. The decoder 12 decodes the received data objects, which could be a streaming data, for the renderer 13 to generate the video to be displayed on the display 14. The display 14 represents or shows the video on the computer screen of the user terminal 10. The Ul unit 11 is configured to interact with a user of the user terminal 10, for example, to receive operations of the user with respect to the application. In some embodiments, the user terminal 10 may include an encoder (not shown) for encoding the video to generate streaming data.

[0020] The CDN server 50 in the embodiment shown in FIG. 2 includes a cache detector 52, a cache storage unit 54, and a TTL management unit 56. The cache detector 52 is configured to check if the CDN server 50 has a requested data object or resource in store from a previously fetching or accessing. The cache storage unit 54 is configured to store data objects (or copies of data objects) from the backend server 30 and/or the streaming server 40 previously fetched by a user terminal 10. The TTL management unit 55 manages the TTL or the time period to be stored in the cache storage unit 54 for each data object.

SUBSTITUTE SHEET (RULE 26) [0021] For example, when the CDN server 50 receives a request, such as an API request, from the user terminal 10 to access a data object in the backend server 30, the cache detector 52 may execute a mapping operation or a comparison operation to detect if the requested data object is stored in the cache storage unit 54. If the requested data object can be found in the cache storage unit 54, which may be referred to as a cache hit, the CDN server 50 transmits the stored data object, or the cached data object, to the user terminal 10, without accessing the backend server 30. If the requested data object can not be found in the cache storage unit 54, which may be referred to as a cache miss, the CDN server 50 may pass the request to the backend server 30 to access the data object. A cache miss may happen when the data object is requested for the first time or the TTL for the data object stored in the cache storage unit 54 (from previously fetching) has expired.

[0022] The backend server 30 in the embodiment shown in FIG. 2 includes a processing unit 31, a storage unit 32, a frequency detection unit 33, and a user number detection unit 34. The backend server 30 receives requests from the CDN server 50 and replies with the corresponding data objects. The backend server 30 may receive an API request from the CDN server 50 and return an API response. The API response may include the requested data object and its corresponding TTL information. The TTL information could be used in the TTL management unit 56 to set the TTL for the data object stored in the cache storage unit 54.

[0023] The storage unit 32 may store various data and programs, including data objects that would be accessed by the user terminal 10 through the CDN server 50. The frequency detection unit 33 is configured to detect or receive an update frequency of a data object. In some embodiments, the frequency detection unit 33 may access an external statistical system, such as Datadog, for the update frequency, which may be done by an API request. The user number detection unit 34 is configured to detect or receive a number of users accessing a data object. In some embodiments, the user number detection unit 34 may access an external database, such as a Datadog database, for the number of users, which may be done by an API request. The processing unit 31 is configured to, among many other functions, determine a TTL for a data object that is to be updated or responded to the CDN server 50 in response to the request from the CDN server 50. In some embodiments, the processing unit 31 determines the TTL based on the update frequency of the data object and/or the number of users accessing the data object.

[0024] In some embodiments, the processing unit 31 is configured as a CPU, a GPU, or the like, reads various programs that may be part of an APP and are stored in the storage unit 32, and executes various kinds of commands or machine-readable instructions included in the programs. In

5

SUBSTITUTE SHEET (RULE 26) some embodiments, each of the above components included in the backend server 30 can be viewed as a processing unit or a processor.

[0025] In some embodiments, the backend server 30 is an origin server for an application providing live streaming service. In this case, data objects in the backend server 30 may include a data object representing or corresponding to a leaderboard of streamers, a data object representing or corresponding to a comment or message information, and/or a data object representing or corresponding to a page of the application, which could be a popular page or a hot page accessed by many users. Data objects in the streaming server 40 may include streaming data from streamers.

[0026] FIG. 3 shows an exemplary sequence chart illustrating an operation of a communication system in accordance with some embodiments of the present disclosure. In some embodiments, FIG. 3 represents how a data object in a backend server is copied, updated or transmitted to a CDN server in response to a request from a user terminal.

[0027] In step S100, the user terminal 10 transmits an API request to the CDN server 50 to request for a data object or a resource which, for example, could represent or correspond to a page, a leaderboard or a message section of an application or a website.

[0028] In step 5102, the CDN server 50 determines if the requested data object is in store. For example, the cache detector 52 may perform a searching operation or a mapping operation to determine whether the requested data object is stored in the cache storage unit 54. In this embodiment, the requested data object cannot be found in the cache storage unit 54, which results in a cache miss, and the flow goes to step 5104.

[0029] In step 8104, the CDN server 50 transmits an API request (or passes the API request of the user terminal 10) to the backend server 30 for the data object requested by the user terminal 10.

[0030] In step $106, the backend server 30 prepares or retrieves the requested data object and determines a TTLfor the data object, which governs how long the data object would be stored on the CDN server 50. Details regarding TTL determination will be described later.

[0031] In step 5108, the backend server 30 transmits an API response to the CDN server 50, which at least includes the requested data object (copy of the data object) and the corresponding TTL information. The TTL information will be used by the TTL management unit 56 of the CDN server 50 to manage the time length of storage for the data object.

SUBSTITUTE SHEET (RULE 26) [0032] In step Slid, the CDN server 50 receives the API response, which includes the requested data object and its TTL information, from the backend server 30. The CDN server 50 may store the data object in the cache storage unit 54 and set the corresponding TTL in the TTL management unit 56 according to the TTL information.

[0033] In step 5112, the CDN server 50 transmits an API response to the user terminal 10, which at least includes the requested data object. Till now, an exemplary round of accessing a data object has been completed and the user terminal 10 may use the received data object for an operation in an application, for example, for checking a leaderboard, viewing a page of the application, or getting the latest comment information.

[0034] In step 5114, the user terminal 10 again transmits an API request to the CDN server 50 for accessing the same data object, which may follow a periodic need or trigger in the application to update a page, a leaderboard or a comment section.

[0035] In step 5116, the CDN server 50 determines if the requested data object is in store. For example, the cache detector 52 may perform a searching operation or a mapping operation to determine whether the requested data object is stored in the cache storage unit 54. In this example, the previously fetched or accessed data object has been stored in the cache storage unit 54 in step 5110, and the corresponding TTL has not expired yet. Therefore, the requested data object can be found in the cache storage unit 54, which results in a cache hit, and the flow goes to step 5118 without the need to access the backend server 30.

[0036] In step 5118, the CDN server 50 transmits an API response to the user terminal 10, which at least includes the requested data object stored in the cache storage unit 54. In this case, the content of the data object is not changed.

[0037] FIG. 4 shows a flowchart illustrating a process in accordance with some embodiments of the present disclosure. FIG. 4 shows how the TTL for the accessed data object may be determined by the backend server 30 in step 5106 in FIG. 3.

[0038] In step 5200, an update frequency of the requested data object is detected or received, for example, by the frequency detection unit 33 of the backend server 30. In some embodiments, the frequency detection unit 33 may access an external database, such as a Datadog database, for the update frequency, which may be done by an API request. The data object may be updated in various ways. For example, a data object corresponding to a leaderboard or a comment section could be updated by posts or input information from various user terminals into a database managing or

7

SUBSTITUTE SHEET (RULE 26) holding the data object, which could be the backend server or a separate database. As another example, a data object corresponding to a hot page or a popular page of an application could be updated by the backend server of the application, therefore there may be no need to access another database for the update frequency.

[0039] In step S202, a maximum time to live TTLmax is determined based on the update frequency of the data object, for example, by the processing unit 31 of the backend server 30. In some embodiments, the TTLmax is determined to be shorter when the update frequency of the data object increases. In some embodiments, the TTLmax is inversely proportional to the update frequency. In some embodiments, the TTLmax is determined to be equal to or less than a reciprocal of the update frequency of the data object. For example, if the update frequency is 2 times per second, the TTLmax may be equal to or less than 7? second. For another example, if the update frequency is 1 time for every 5 seconds, the TTLmax may be equal to or less than 5 seconds. In some embodiments, signal transmission latency in the Internet can be taken into account and the TTLmax may be set to have a predetermined offset from the reciprocal of the update frequency, wherein the predetermined offset is used to cover or compensate for the signal transmission latency or an API response time and could be determined according to actual practice such as network conditions. For example, if the update frequency is 1 time for every 5 seconds, the TTLmax may be equal to (5-2) seconds, wherein 5 is the reciprocal of the frequency and 2 is the predetermined offset.

[0040] In step S204, a number of users accessing the data object is detected or received, for example, by the user number detection unit 34 of the backend server 30. In some embodiments, the user number detection unit 34 may access an external database, such as a Datadog database, for the number of users, which may be done by an API request.

[0041] In step 5205, a minimum time to live TTLmin is determined based on the number of users accessing the data object, for example, by the processing unit 31 of the backend server 30. In some embodiments, the TTLmin is determined to be longer when the number of users accessing the data object increases. In some embodiments, the TTLmin is determined such that an estimated QPS from the number of users reaching the backend server providing the data object after the TTLmin expires is below a maximum QPS capacity of the backend server.

[0042] In step 5208, a TTL for the data object is determined based on the maximum time to live TTLmax and the minimum time to live TTLmin, for example, by the processing unit 31 of the backend server 30. In some embodiments, the TTL is determined to be equal to or greater than the TTLmin. In some embodiments, the TTL is determined to be equal to or less than the TTLmax. In some

8

SUBSTITUTE SHEET (RULE 26) embodiments, the TTL is determined to be equal to or less than the TTLmax and equal to or greater than the TTLmin. In some embodiments, the TTL is determined to be TTLmin if TTLmax is equal to or less than TTLmin.

[0043] In some embodiments, the maximum time to live TTLmax sets a maximum value for the TTL, thereby to make sure the user terminal always gets the latest version of the data object. For a data object with a higher update frequency, the corresponding TTLmax would be set shorter and the data object would exist for a shorter time on the CDN server. Therefore, requests of the data object from user terminals would need to go through the CDN server to access the backend server (once the TTLmax expires and the data object cannot be found on the CDN server) at a higher frequency to get the latest version of the data object. In some embodiments, for a data object with a lower update frequency, the corresponding TTLmax would be set longer and the data object would exist for a longer time on the CDN server. Therefore, requests of the data object from user terminals would need to go through the CDN server to access the backend server (once the TTLmax expires and the data object cannot be found on the CDN server) at a lower frequency, which may release a burden for the backend server.

[0044] In some embodiments, the update frequency of the data object may be monitored or tracked constantly or periodically, for example, by the frequency detection unit 33 of the backend server 30 in FIG. 2. The processing unit 31 may utilize the constantly monitored update frequency to determine the TTLmax constantly, and then determine the TTL based on the TTLmax and the TTLmin. In some embodiments, the backend server 30 may constantly update the TTL information to the CDN server 50 to set the TTL for the corresponding data object stored in the CDN server 50. In some embodiments, the backend server 30 may update the TTL information to the CDN server 50 once a change in the update frequency of the data object is detected, to ensure that the data object accessed by the user terminal is at its latest version. In some embodiments, the TTL update may not need a request from the CDN server 50.

[0045] In some embodiments, the minimum time to live TTLmin sets a minimum value for the TTL, thereby to prevent the backend server from being overwhelmed or overburdened by requests from the user terminals, for example, in a timing right after the TTLmin expires and/or in a timing before the data object is transmitted or copied to the cache server. For a data object accessed by a greater number of user terminals, the corresponding TTLmin would be set longer and the data object would exist for a longer time on the CDN server. Therefore, requests of the data object from user terminals would not need to go through the CDN server to access the backend server for a longer time period

9

SUBSTITUTE SHEET (RULE 26) when the number of users accessing the data object is still high, and the risk of backend server crashdown or access failure can be reduced.

[0046] In some embodiments, the TTLmin may be determined by an estimated number of users that are going to access the corresponding data object in an upcoming timing, which may be, for example, 10 seconds, 30seconds, or 1 min later. The estimated number of users may be achieved by various estimation mechanisms, which may include machine learning algorithms trained by historical data such as user behavioral data, application events data and/or their correlation data. For example, the TTLmin can be set to a length after which the number of users accessing the data object is estimated or expected to decrease to a level that would not put the backend server at a crashdown risk or would not cause access failures.

[0047] In some embodiments, the number of users accessing the data object may be monitored or tracked constantly or periodically, for example, by the user number detection unit 34 of the backend server 30 in FIG. 2. The processing unit 31 utilizes the constantly monitored number of accessing users to determine the TTLmin constantly, and then determine the TTL based on the TTLmax and the TTLmin. In some embodiments, the backend server 30 may constantly update the TTL information to the CDN server 50 to set the TTL for the corresponding data object stored in the CDN server 50. In some embodiments, the TTL update may not need a request from the CDN server 50. For example, for a data object that is expected to be accessed by a large number of users (for example, a data object corresponding to a hot page of an application), the backend server 30 may continuously or constantly update the TTL setting according to the number of accessing users in real-time. As described above, the determination of TTL always takes the latest number of accessing users into consideration and therefore can minimize the risk of backend server crashdown or accessing failures after the TTL expires in the CDN server. In some embodiments, the TTLmin (and hence the TTL) may be determined and/or updated to the CDN server more frequently when the corresponding data object is accessed by more user terminals.

[0048] There may be a situation wherein the TTLmax is equal to or less than the TTLmin. For example, if a data object has a high update frequency and is accessed by a large number of users, the data object may have a short TTLmax and a long TTLmin. In some embodiments, the TTL would be determined to be TTLmin if the TTLmax is equal to or less than the TTLmin. That is, in some embodiments, TTLmin may have a higher priority or importance weight than TTLmax when determining the TTL, since one purpose for TTLmin is to protect the backend server from being overburdened or crashed.

10

SUBSTITUTE SHEET (RULE 26) [0049] Another benefit of determining the TTL based on the TTLmin is that a complicated mechanism for alleviating the burden for the backend server may be omitted or simplified. For example, a rate limiting mechanism or an implementation of extra backend servers may be saved. In some embodiments, a server load balancing mechanism which may need extra infrastructure implementation or a complicated cache server with the ability to efficiently distribute or balance loading for the backend server may be saved. Therefore, the cost of operating the corresponding application can be saved.

[0050] The processing and procedures described in the present disclosure may be realized by software, hardware, or any combination of these in addition to what was explicitly described. For example, the processing and procedures described in the specification may be realized by implementing a logic corresponding to the processing and procedures in a medium such as an integrated circuit, a volatile memory, a non-volatile memory, a non-transitory computer-readable medium and a magnetic disk. Further, the processing and procedures described in the specification can be implemented as a computer program corresponding to the processing and procedures, and can be executed by various kinds of computers.

[0051] Furthermore, the system or method described in the above embodiments may be integrated into programs stored in a computer-readable non-transitory medium such as a solid state memory device, an optical disk storage device, or a magnetic disk storage device. Alternatively, the programs may be downloaded from a server via the Internet and be executed by processors.

[0052] Although technical content and features of the present invention are described above, a person having common knowledge in the technical field of the present invention may still make many variations and modifications without disobeying the teaching and disclosure of the present invention. Therefore, the scope of the present invention is not limited to the embodiments that are already disclosed, but includes another variation and modification that do not disobey the present invention, and is the scope covered by the patent application scope.

Description of reference numerals

I Communication system

10 User terminal

II Ul unit

12 Decoder

13 Renderer

11

SUBSTITUTE SHEET (RULE 26) Display

Backend server

Processing unit

Storage unit

Frequency detection unit

User number detection unit

Streaming server

CDN server

Cache detector

Cache storage unit

TTLmanagement unit

Network

12

SUBSTITUTE SHEET (RULE 26)

Claims

CLAIMS We Claim:

1. A method for determining a time to live (TTL) for a data object on a cache server, comprising: detecting an update frequency of the data object; detecting a number of users accessing the data object; and determining the TTL based on the update frequency and the number of users.

2. The method according to claim 1, further comprising determining a minimum time to live (TTLmin) based on the number of users accessing the data object, wherein the TTLmin is determined to be longer when the number of users accessing the data object increases, and the TTL is determined to be equal to or greater than the TTLmin.

3. The method according to claim 1, further comprising determining a maximum time to live (TTLmax) based on the update frequency of the data object, wherein the TTLmax is determined to be shorter when the update frequency of the data object increases, and the TTL is determined to be equal to or less than the TTLmax.

4. The method according to claim 1, further comprising: determining a minimum time to live (TTLmin) based on the number of users accessing the data object, wherein the TTLmin is determined to be longer when the number of users accessing the data object increases; and determining a maximum time to live (TTLmax) based on the update frequency of the data object, wherein the TTLmax is determined to be shorter when the update frequency of the data object increases, and the TTL is determined to be equal to or less than the TTLmax and equal to or greater than the TTLmin.

5. The method according to claim 4, wherein the TTL is determined to be TTLmin if the TTLmax is equal to or less than TTLmin.

6. The method according to claim 2, wherein the TTLmin is determined such that an estimated maximum query per second (QPS) from the number of users reaching a backend server providing the data object after the TTLmin expires is below a maximum Q.PS capacity of the backend server.

13

SUBSTITUTE SHEET (RULE 26)

7. The method according to claim 3, wherein the TTLmax is determined to be equal to or less than a reciprocal of the update frequency of the data object.

8. The method according to claim 1, wherein the data object corresponds to a page of an application.

9. The method according to claim 1, wherein the data object corresponds to a leaderboard of an application.

10. The method according to claim 1, further comprising: constantly detecting the number of users accessing the data object; constantly determining the TTL based on the update frequency and the constantly detected number of users; and constantly updating the TTL to the cache server.

11. The method according to claim 4, wherein the number of users accessing the data object is constantly detected and the TTLmin is constantly determined based on the constantly detected number of users accessing the data object, the TTL is constantly determined to be equal to or less than the TTLmax and equal to or greater than the TTLmin, and the TTL is constantly updated to the cache server.

12. A system for determining a time to live (TTL) for a data object on a cache server, comprising one or a plurality of processors, wherein the one or plurality of processors execute a machine-readable instruction to perform: detecting an update frequency of the data object; detecting a number of users accessing the data object; and determining the TTL based on the update frequency and the number of users.

13. The system according to claim 12, wherein the one or plurality of processors execute the machine-readable instruction to further perform: determining a minimum time to live (TTLmin) based on the number of users accessing the data object, wherein the TTLmin is determined to be longer when the number of users accessing the data object increases, and the TTL is determined to be equal to or greater than the TTLmin.

14

SUBSTITUTE SHEET (RULE 26)

14. The system according to claim 12, wherein the one or plurality of processors execute the machine-readable instruction to further perform: determining a maximum time to live (TTLmax) based on the update frequency of the data object, wherein the TTLmax is determined to be shorter when the update frequency of the data object increases, and the TTL is determined to be equal to or less than the TTLmax.

15. The system according to claim 12, wherein the one or plurality of processors execute the machine-readable instruction to further perform: determining a minimum time to live (TTLmin) based on the number of users accessing the data object, wherein the TTLmin is determined to be longer when the number of users accessing the data object increases; and determining a maximum time to live (TTLmax) based on the update frequency of the data object, wherein the TTLmax is determined to be shorter when the update frequency of the data object increases, and the TTL is determined to be equal to or less than the TTLmax and equal to or greater than the TTLmin.

16. The system according to claim 15, wherein the TTL is determined to be TTLmin if the TTLmax is equal to or less than TTLmin.

17. The system according to claim 12, wherein the one or plurality of processors execute the machine-readable instruction to further perform: constantly detecting the number of users accessing the data object; constantly determining the TTL based on the update frequency and the constantly detected number of users; and constantly updating the TTL to the cache server.

18. The system according to claim 15, wherein the number of users accessing the data object is constantly detected and the TTLmin is constantly determined based on the constantly detected number of users accessing the data object, the TTL is constantly determined to be equal to or less than the TTLmax and equal to or greater than the TTLmin, and the TTL is constantly updated to the cache server.

19. A non-transitory computer-readable medium including a program for determining a time

15

SUBSTITUTE SHEET (RULE 26) to live (TTL) for a data object on a cache server, wherein the program causes one or a plurality of computers to execute: detecting an update frequency of the data object; detecting a number of users accessing the data object; and determining the TTL based on the update frequency and the number of users.

20. The non-transitory computer-readable medium according to claim 19, wherein the program causes the one or plurality of computers to further execute: determining a minimum time to live (TTLmin) based on the number of users accessing the data object, wherein the TTLmin is determined to be longer when the number of users accessing the data object increases; and determining a maximum time to live (TTLmax) based on the update frequency of the data object, wherein the TTLmax is determined to be shorter when the update frequency of the data object increases, and the TTL is determined to be equal to or less than the TTLmax and equal to or greater than the TTLmin.

16

SUBSTITUTE SHEET (RULE 26)