JP2023548722A - SYSTEMS, METHODS AND COMPUTER-READABLE MEDIA FOR DETERMINING Cache TTL - Google Patents

Abstract

A system, method, and computer-readable medium for determining a cache TTL is provided. The present invention relates to a system, method, and computer-readable medium for determining the time to live (TTL) of a data object on a cache server, the method determining the update frequency of the data object. detecting, detecting the number of users accessing the data object, and determining a TTL based on the update frequency and the number of users, the present invention provides the latest data object to the user. , the backend server can be protected from overload. [Selection diagram] Figure 4

Description

FIELD OF THE INVENTION The present invention relates to the storage of information on the Internet, and more particularly to the storage of data objects on Internet caches.

Caches and caching technologies are applied and utilized across technologies such as operating systems, network layers including CDNs (content delivery networks), domain name systems (DNS), web applications, and databases. Use caching to reduce latency and improve input/output operations per second (IOPS) for many read-intensive application workloads, such as Q&A portals, gaming, media sharing, content streaming, and social networking. Can be done. Cached information includes results of queries to databases, computationally intensive calculations, application programming interface (API) requests/responses, and web artifacts such as HTML, JavaScript, and image files.

Caching is very important for CDN services. A CDN moves content/data objects and copies of them from back-end servers, such as website servers or application back-end servers, to proxy servers or caching servers for use by website visitors or applications accessed by neighbors. Give users quick access to content.

TTL (Time to Live) is the time from when a content/data object (or a copy of a content/data object) is stored in a cache system such as a cache server until it is deleted or refreshed. In the context of a CDN, TTL generally refers to content caching, which stores a copy of resources (images, prices, text, streaming content, etc.) on a website or application server on a CDN cache server to improve page load speed. It is a process that improves and reduces bandwidth consumption and workload on origin servers.

A method according to an embodiment of the present invention is a method for determining a TTL (Time to Live) of a data object on a cache server, which is executed by one or more computers. Detecting the update frequency of the data object, detecting the number of users accessing the data object, and determining the TTL based on the update frequency and the number of users.

According to one embodiment of the invention, a system for determining a TTL of a data object on a cache server includes one or more processors, the one or more computer processors having a machine-readable Executing the instruction and detecting the update frequency of the data object; detecting the number of users accessing the data object; and determining the TTL based on the update frequency and the number of users. Execute.

According to one embodiment of the present invention, a computer-readable medium is a non-transitory computer-readable medium that includes a program for determining a TTL of a data object on a cache server, the computer-readable medium comprising: a program for determining a TTL of a data object on a cache server; , detecting the update frequency of the data object, detecting the number of users accessing the data object, and determining the TTL based on the update frequency and the number of users.

1 is a schematic diagram illustrating a configuration of a communication system according to some embodiments of the present invention. FIG. 1 is an exemplary functional block diagram of a communication system according to some embodiments of the present invention. FIG. 1 is an exemplary sequence diagram illustrating the operation of a communication system according to some embodiments of the present invention. FIG. 1 is a flowchart illustrating steps according to some embodiments of the invention.

The TTL of a data object governs the update rate of the data object (or a copy of the data object) on a cache server and informs visitors to applications and websites that have access to the data object that the data object is ``stale''. Ideally, you should ensure that no ``version'' is provided. TTL directly impacts an application or website's page load time (i.e. cached data will load faster) and content freshness (i.e. data cached for a long time may become stale) .

Static files and data objects (image files, PDFs, etc.) typically have longer TTLs because they are rarely updated. For example, a collection of product images on an e-commerce site corresponds to static content. Since these are rarely updated, they can be cached for long periods of time (eg, days or weeks). Therefore, TTL settings are predictable and easy to maintain.

Conversely, dynamic content and data objects (such as HTML files) are constantly updated, making setting an accurate TTL complicated. For example, a comment section under a product is considered dynamic content because it changes frequently. If the TTL is set too long, comments will not be reflected in time.

Another consideration in setting TTL is the number of users accessing the data object. If you set the TTL too short when many users are trying to access the data object in question, when the TTL expires, many users will not get a response on the cache server and will access the data object's origin server. (There are cases where the origin server is accessed directly and accesses via a cache server). When more users access an origin server than the maximum capacity the origin server can support, the queries per second (QPS) of the origin server typically becomes excessive or overloaded, causing the server to crash down or users may not be able to successfully access data.

Therefore, based on factors such as the data object's update frequency and the number of users accessing the data object, how to determine the TTL on a data object's cache server provides the freshest data and the most user-accessible This is extremely important to prevent failures and protect origin servers from outages. In some implementations, a data object may be referred to as a resource or resource data.

FIG. 1 shows a schematic diagram showing the configuration of a communication system 1 based on some embodiments of the present invention. The communication system 1 can provide live streaming services with interaction through content. "Content" here refers to digital content that can be played back on a computer device. In other words, the communication system 1 allows users to participate in real-time interactions with other users online. The communication system 1 includes a plurality of user terminals 10, a backend server 30, and a streaming server 40. The user terminal 10, the backend server 30, and the streaming server 40 are connected via a network 90 (for example, the Internet may be used). Backend server 30 may be a server that synchronizes interactions between user terminals and/or streaming server 40 . In some implementations, backend server 30 may be an application (APP) provider's origin server. Streaming server 40 is a server for handling or providing streaming data or video data. In some implementations, backend server 30 and streaming server 40 may be independent servers. In some implementations, backend server 30 and streaming server 40 may be integrated into one server. In some implementations, user terminal 10 is a client device for live streaming. In some implementations, user terminal 10 may be referred to as a viewer, streamer, anchor, podcaster, audience, listener, etc. The user terminal 10, the backend server 30, and the streaming server 40 are each examples of information processing devices. In some implementations, streaming can be live streaming or video playback. In some implementations, streaming can be audio streaming and/or video streaming. In some implementations, streaming can include content such as online shopping, talk shows, talent shows, entertainment events, sporting events, music videos, movies, comedies, concerts, and the like.

FIG. 2 shows an exemplary functional configuration diagram of the communication system 1. In FIG. 2, the network 90 is omitted and a CDN server 50 connecting the user terminal 10 and the back-end server 30 is shown. The CDN server 50 may be part of the network 90. In some implementations, the CDN server 50 may function as a cache server.

In this embodiment, the user terminal 10 includes a UI unit 11, a decoder 12, a renderer 13, and a display 13. The user terminal 10 can access the backend server 30 and the streaming server 40 of the data object via the CDN server 50, for example, by sending an API request and receiving an API response. . The decoder 12 decodes the received data object (which may be streaming data) and generates a video that the renderer 13 displays on the display 14 . The display 14 depicts or displays the image on the computer screen of the user terminal 10. The UI unit 11 is configured to interact with the user of the user terminal 10, and receives, for example, the user's operations regarding applications. In some implementations, the user terminal 10 may include an encoder (not shown) to encode video and generate streaming data.

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 whether the CDN server 50 stores the requested data object or resource when previously obtained or accessed. 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 obtained by the user terminal 10 . The TTL management unit 55 manages the TTL or the period of time that each data object is stored in the cache storage unit 54 .

For example, when the CDN server 50 receives a request (such as an API request) for accessing a data object in the backend server 30 from the user terminal 10, the cache detection unit 52 executes a mapping operation or a comparison operation. and detect whether the requested data object is stored in the cache storage unit 54. If the requested data object is found in the cache storage unit 54 (sometimes referred to as a cache hit), the CDN server 50 retrieves the stored or cached data object without accessing the backend server 30. The data object is sent to the user terminal 10. If the requested data object is not found in the cache storage unit 54 (sometimes referred to as a cache miss), the CDN server 50 may pass the request to the backend server 30 to access the data object. can. A cache miss may occur when the data object is requested for the first time or when the TTL of the data object stored in the cache storage unit 54 (when previously retrieved) has expired.

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 responds with corresponding data objects. The backend server 30 can 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 may be used by the TTL management unit 56 to set the TTL for the data object stored in the cache storage unit 54.

The storage unit 32 can store a variety of data and programs, including data objects accessed by the user terminal 10 via the CDN server 50. The frequency detection unit 33 is configured to detect or receive the update frequency of the data object. In some implementations, the frequency detection unit 33 may access an external statistics system, such as Datadog, for the update frequency, and this may be done by an API request. The number of users detection unit 34 is configured to detect or receive the number of users accessing the data object. In some implementations, the user count detection unit 34 may access an external database, such as a Datadog database, for the user count, and this may be done by an API request. The processing unit 31, among many other functions, causes the CDN server 50, in response to a request from the CDN server 50, to determine the TTL of a data object being updated or responded to to the CDN server 50. It is composed of In some implementations, 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.

In some embodiments, the processing unit 31 is configured as a CPU, GPU, etc., and reads various programs stored in the storage unit 32, which may be part of an application, and reads various commands and commands included in the programs. Execute machine-readable instructions. In some implementations, each of the above-mentioned components included in the backend server 30 may be considered a processing device or processor.

In some implementations, the backend server 30 is an origin server for an application that provides live streaming services. In this case, the data objects in the backend server 30 may be data objects representing or corresponding to a leaderboard of streamers, data objects representing or corresponding to comment or message information, and/or data objects representing or corresponding to a leaderboard of streamers, and/or data objects representing or corresponding to a leaderboard of streamers, It may include data objects representing or corresponding to pages of the application, which may be popular or hot pages to access. The data object of the streaming server 40 may include streaming data from a streamer.

FIG. 3 depicts an exemplary sequence diagram illustrating the operation of a communication system according to some embodiments of the present invention. In some implementations, FIG. 3 illustrates how data objects in a backend server are copied, updated, or sent to a CDN server in response to a request from a user terminal.

In step S100, the user terminal 10 sends an API request to the CDN server 50, requesting a data object or resource that may represent or correspond to a page, leaderboard, message section of an application or website, for example. .

In step S102, the CDN server 50 determines whether the requested data object is stored. For example, the cache detector 52 performs a search or mapping operation to determine whether the requested data object is stored in the cache storage unit 54 . In this embodiment, the requested data object is not found in cache storage unit 54, resulting in a cache miss and flow proceeds to step S104.

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

In step S106, the backend server 30 prepares or obtains the requested data object and determines the TTL of the data object, which determines how long the data object will be stored in the CDN server 50. Applicable. Details regarding the determination of TTL will be described later.

In step S108, the backend server 30 sends an API response to the CDN server 50, including at least TTL information corresponding to the requested data object (a copy of the data object). The TTL information is used by the TTL management unit 56 of the CDN server 50 to manage the length of the data object's retention period.

In step S110, the CDN server 50 receives the API response including 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.

In step S112, the CDN server 50 transmits an API response including at least the requested data object to the user terminal 10. By now, an exemplary round of accessing a data object has been completed, and the user terminal 10 can use the received data object for operations in an application, such as checking a leaderboard, displaying a page of an application, or providing information on the latest comments. It can be used for acquisition.

In step S114, the user terminal 10 again sends an API request to the CDN server 50 for accessing the same data object, but this is a regular request in the application for updating the page, leaderboard, or comment field. may be executed according to a specific request or trigger.

In step S116, the CDN server 50 determines whether the requested data object is stored. For example, the cache detector 52 performs a search or mapping operation to determine whether the requested data object is stored in the cache storage unit 54 . In this example, a previously obtained or accessed data object was stored in the cache storage unit 54 at step S110 and the corresponding TTL has not yet expired. Therefore, the requested data object can be found in the cache storage unit 54, resulting in a cache hit and flow proceeds to step S118 without the need to access the backend server 30.

In step S118, the CDN server 50 sends to the user terminal 10 an API response that includes at least the requested data object stored in the cache storage unit 54. In this case, the contents of the data object remain unchanged.

FIG. 4 shows a flowchart of steps according to some embodiments of the invention. FIG. 4 shows how the TTL of the accessed data object may be determined by the backend server 30 in step S106 of FIG.

In step S200, the 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 implementations, the frequency detection unit 33 may access an external database, such as the Datadog database, for the update frequency, and this 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 field is updated by posts and input information from various user terminals to a database (which may be the backend server or another database) that manages or maintains the data object. There is a possibility that As another example, data objects corresponding to hot or popular pages of an application may be updated by the application's backend server and thus may not require access to a separate database for update frequency. .

In step S202, the maximum cache retention time TTLmax is determined, for example, by the processing unit 31 of the backend server 30, based on the update frequency of the data object. In some implementations, the TTLmax is determined to be shorter when the data object is updated more frequently. In some implementations, the TTLmax is inversely proportional to the update frequency. In some implementations, the TTLmax is determined to be less than or equal to the inverse of the update frequency of the data object. For example, if the update frequency is 2 times per second, TTLmax may be less than or equal to 1/2 second. Further, as another example, if the update frequency is once every 5 seconds, TTLmax can be set to 5 seconds or less. In some implementations, considering the signal transmission delay in the Internet, TTLmax may be set to have a predetermined offset from the inverse of the update frequency, in which the predetermined offset is the signal transmission delay or the API response time. may be used to cover or compensate, and may be determined according to actual practice such as network conditions. For example, if the update frequency is once every 5 seconds, TTLmax may be equal to (5-2) seconds, where 5 is the reciprocal of the frequency and 2 is the predetermined offset.

In step S204, the 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 implementations, the user count detection unit 34 may access an external database, such as a Datadog database, for the user count, and this may be done by a PI request.

In step S206, a minimum cache retention time TTLmin is determined, for example, by the processing unit 31 of the backend server 30, based on the number of users accessing the data object. In some implementations, the TTLmin is determined to be longer when the number of users accessing the data object increases. In some implementations, the TTLmin is such that the estimated QPS from the number of users reaching the backend server serving the data object after the TTLmin expires is less than or equal to the maximum QPS capacity of the backend server. It is determined as follows.

In step S208, the TTL of the data object is determined, for example, by the processing unit 31 of the backend server 30, based on the maximum cache retention time TTL and the minimum cache retention time TTLmin. In some embodiments, the TTL is determined to be equal to or greater than the TTLmin. In some implementations, the TTL is determined to be less than or equal to the TTLmax. In some implementations, the TTL is determined to be less than or equal to the TTLmax and greater than or equal to the TTLmin. In some implementations, the TTL is determined as TTLmin if TTLmax is less than or equal to TTLmin.

In some implementations, the maximum cache retention time TTLmax sets a maximum value for TTL, thereby ensuring that the user terminal always obtains the latest version of the data object. For data objects that are updated frequently, the corresponding TTLmax is set short, and the time that the data object exists on the CDN server is shortened. Therefore, requests for the data object from the user terminal will be sent to the backend server via the CDN server more frequently (when the TTLmax expires and the data object is no longer found on the CDN server). You will need to access and obtain the latest version of the data object. In some implementations, for data objects with low update frequency, the corresponding TTLmax is set longer and the data objects exist on the CDN server for a longer time. Therefore, a request for the data object from the user terminal needs to access the backend server via the CDN server (when the TTLmax expires and the data object is no longer found on the CDN server). This may reduce the frequency of errors and reduce the burden on the backend server.

In some implementations, the update frequency of a data object may be constantly or periodically monitored or tracked, for example by the frequency detection unit 33 of the backend server 30 in FIG. 2. The processing unit 31 may constantly determine TTLmax using the constantly monitored update frequency, and may determine TTL based on TTLmax and TTLLmin. In some implementations, the backend server 30 may constantly update TTL information to the CDN server 50 to set the TTL for the corresponding data object stored on the CDN server 50. good. In some implementations, the backend server 30 updates the TTL information for the CDN server 50 when a change in the update frequency of the data object is detected, so that the data object accessed by the user terminal version can be guaranteed. In some implementations, updating the TTL may not require a request from the CDN server 50.

In some implementations, the minimum cache retention time TTLmin is determined by setting a minimum value for the TTL, such as the timing immediately after TTLmin expires and/or the timing before the data object is sent or copied to the cache server. This prevents the backend server from being overwhelmed or overloaded by requests from user terminals. For a data object that is accessed by many user terminals, the corresponding TTLmin is set longer and the data object exists on the CDN server for a longer time. Therefore, if the number of users accessing the data object is still large, requests for the data object from user terminals will not need to access the backend server via the CDN server for a longer time, and the backend This makes it possible to reduce the risk of server crashes and access failures.

In some implementations, TTLmin may be determined by the estimated number of users who will attempt to access the corresponding data object at a future time, such as in 10 seconds, 30 seconds, or 1 minute. The estimated number of users may be achieved by various estimation mechanisms, including machine learning algorithms trained with historical data such as user behavior data, application event data, and/or correlation data thereof. For example, TTLmin may be set to a length that is estimated or expected to reduce the number of users accessing the data object to a level that does not put the backend server at risk of crashing or causing access failure. can.

In some implementations, the number of users accessing the data object may be constantly or periodically monitored or tracked, for example by the user number detection unit 34 of the backend server 30 in FIG. 2. The processing unit 31 constantly determines TTLmin using the constantly monitored number of access users, and determines TTL based on TTLmax and TTLmin. In some implementations, the backend server 30 may constantly update TTL information to the CDN server 50 to set the TTL for the corresponding data object stored on the CDN server 50. good. In some implementations, updating the TTL may not require a request from the CDN server 50. For example, in the case of a data object that is expected to be accessed by a large number of users (e.g., a data object corresponding to a hot page of an application), the backend server 30 uses a TTL Settings can be updated continuously or constantly. As described above, the TTL is determined always taking into account the latest number of users accessing the CDN server, thereby avoiding the risk of crashing or failure of access after the TTL expires in the CDN server. In some implementations, TTLmin (and TTL) may be determined and/or updated more frequently for the CDN server if the corresponding data object is accessed by more user terminals.

There may also be a situation where TTLmax is equal to or less than TTLmin. For example, if a data object is frequently updated and accessed by many users, the data object may have a short TTLmax and a long TTLmin. In some implementations, if TTLmax is less than or equal to TTLmin, the TTL is determined to be TTLmin. That is, in some implementations, when determining TTL, TTLmin may have a higher priority or importance weight than TTLmax because one of the purposes of TTLmin is to protect the backend server from overloading or crashing. This is because it is to protect.

Further, by determining the TTL based on TTLmin, there is an advantage that a complicated mechanism for reducing the load on the back-end server can be omitted and simplified. For example, it is possible to eliminate the need for a communication speed limit mechanism or the addition of back-end servers. In some implementations, server load balancing mechanisms that may require additional infrastructure implementation or complex caching servers with the ability to efficiently load balance backend servers may be omitted. Therefore, the operating cost of the corresponding application can be reduced.

The processes and procedures described in this invention, in addition to those explicitly described, may be implemented by software, hardware, or any combination thereof. For example, the processes and procedures described herein implement logic corresponding to the processes and procedures in a medium such as an integrated circuit, volatile memory, non-volatile memory, non-transitory computer-readable medium, magnetic disk, etc. This can be achieved by Further, the processes and procedures described in this specification can be realized as a computer program corresponding to the processes and procedures, and can be executed by various computers.

Additionally, the systems or methods described in the above embodiments may be integrated into programs stored on non-transitory computer-readable media, such as solid state storage, optical disk storage, magnetic disk storage, and the like. Alternatively, the program may be downloaded from a server via the Internet and executed by the processor.

Although the technical contents and features of the present invention have been described above, those with ordinary knowledge in the technical field to which the present invention pertains will appreciate that many variations and modifications can be made without departing from the teachings and disclosure of the present invention. It can be performed. Therefore, the scope of the invention is not limited to the embodiments already disclosed, but includes other variations and modifications that do not depart from the invention and are included in the scope of the claims.

1 Communication system 10 User terminal 11 UI unit 12 Decoder 13 Renderer 14 Display 30 Back-end server 31 Processing unit 32 Storage unit 33 Frequency detection unit 34 Number of users detection unit 40 Streaming server 50 CDN server 52 Cache detection unit 54 Cache storage unit 56 TTL Management unit 90 network

Claims (20)

A method for determining a TTL (Time to Live, cache retention time) for a data object on a cache server, the method comprising:
detecting an update frequency of the data object;
detecting the number of users accessing the data object;
determining a TTL based on the update frequency and the number of users;
A method for determining a cache TTL, the method comprising: The method further includes determining a minimum cache retention time (TTLmin) based on the number of users accessing the data object, wherein when the number of users accessing the data object increases, the TTLmin becomes longer. 2. The method of claim 1, wherein the TTL is determined to be greater than or equal to the TTLmin. The method further includes determining a maximum cache retention time (TTLmax) based on the update frequency of the data object, wherein when the update frequency of the data object increases, the TTLmax is set to a short time and the TTL is increased. The method of determining a cache TTL according to claim 1, characterized in that the cache TTL is determined to be less than or equal to the TTLmax. Further, determining a minimum cache retention time (TTLmin) based on the number of users accessing the data object, wherein when the number of users accessing the data object increases, the TTLmin is determined to be a longer time. and,
A maximum cache retention time (TTLmax) is determined based on the update frequency of the data object, and when the update frequency of the data object increases, the TTLmax is set to a short time, the TTL is less than or equal to the TTLmax, and A step determined to be equal to or greater than TTLmin;
A method for determining a cache TTL according to claim 1, characterized in that the method comprises: The method of claim 4, wherein if the TTLmax is less than or equal to TTLmin, the TTL is determined to be TTLmin. The maximum number of queries per second (QPS) estimated from the number of users reaching the backend server serving the data object after the TTLmin expires is less than the maximum QPS capacity of the backend server. The method of determining cache TTL according to claim 2, characterized in that TTLmin is determined. A method for determining a cache TTL according to claim 3, characterized in that the TTLmax is determined to be equal to or less than the reciprocal of the update frequency of the data object. The method of determining a cache TTL according to claim 1, characterized in that the data object corresponds to a page of an application. The method of determining a cache TTL according to claim 1, characterized in that the data object corresponds to a leaderboard of an application. Further, 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;
constantly updating the TTL to the cache server;
A method for determining a cache TTL according to claim 1, characterized in that the method comprises: The number of users accessing the data object is constantly detected, and the TTLmin is always determined based on the constantly detected number of users accessing the data object, and the TTL is less than or equal to the TTLmax and greater than or equal to the TTLmin. 5. The method of determining a cache TTL according to claim 4, wherein the cache TTL is constantly determined and the TTL is constantly updated to the cache server. A system for determining a TTL (Time to Live) for a data object on a cache server, the system comprising one or more processors, the one or more processors executing machine-readable instructions,
detecting an update frequency of the data object;
detecting the number of users accessing the data object;
determining a TTL based on the update frequency and the number of users;
A system for determining a cache TTL, characterized in that the system performs the following: The one or more processors execute the machine readable instructions, and further:
determining a minimum cache retention time (TTLmin) based on the number of users accessing the data object, wherein when the number of users accessing the data object increases, the TTLmin is determined to be a longer time; and the TTL is determined to be greater than or equal to the TTLmin;
13. A system for determining a cache TTL according to claim 12. The one or more processors execute the machine readable instructions, and further:
determining a maximum cache retention time (TTLmax) based on the update frequency of the data object, wherein when the update frequency of the data object increases, the TTLmax is set to a shorter time; determined to be less than or equal to TTLmax,
13. A system for determining a cache TTL according to claim 12. The one or more processors execute the machine readable instructions, and further:
determining a minimum cache retention time (TTLmin) based on the number of users accessing the data object, wherein when the number of users accessing the data object increases, the TTLmin is determined to be a longer time; ,
determining a maximum cache retention time (TTLmax) based on the update frequency of the data object, wherein when the update frequency of the data object increases, the TTLmax is set to a shorter time; determined to be less than or equal to TTLmax and greater than or equal to TTLmin,
13. A system for determining a cache TTL according to claim 12. The system of claim 15, wherein if the TTLmax is less than or equal to TTLmin, the TTL is determined to be TTLmin. The one or more processors execute the machine readable instructions, and further:
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;
constantly updating the TTL to the cache server;
13. The system for determining a cache TTL as recited in claim 12. The number of users accessing the data object is constantly detected, and the TTLmin is always determined based on the constantly detected number of users accessing the data object, and the TTL is less than or equal to the TTLmax and greater than or equal to the TTLmin. 16. The system for determining a cache TTL according to claim 15, wherein the TTL is constantly determined to the cache server. A non-transitory computer-readable medium comprising a program for determining a time-to-live (TTL) for a data object on a cache server, the program comprising:
detecting an update frequency of the data object;
detecting the number of users accessing the data object;
determining a TTL based on the update frequency and the number of users;
A computer readable medium for executing. The program is installed on one or more computers,
determining a minimum cache retention time (TTLmin) based on the number of users accessing the data object, in which when the number of users accessing the data object increases, the TTLmin is determined to be a longer time;
A maximum cache retention time (TTLmax) is determined based on the update frequency of the data object, and when the update frequency of the data object increases, the TTLmax is set to a short time, the TTL is less than or equal to the TTLmax, and A step determined to be equal to or greater than TTLmin;
20. The computer-readable medium of claim 19, wherein the computer-readable medium executes the following steps.