Content request pattern-based routing system

Some content providers attempt to facilitate the delivery of requested content, such as network pages (e.g., content pages, Web pages, etc.) and/or resources identified in network pages, through the utilization of a network storage provider or a content delivery network (“CDN”) service provider. A network storage provider and a CDN service provider each typically maintain a number of computing devices in a communication network that can maintain content from various content providers. In turn, content providers can instruct, or otherwise suggest to, client computing devices to request some, or all, of the content provider's content from the network storage provider's or CDN service provider's computing devices.

As with content providers, network storage providers and CDN service providers are also generally motivated to provide requested content to client computing devices often with consideration of efficient transmission of the requested content to the client computing device and/or consideration of a cost associated with the transmission of the content. Accordingly, CDN service providers often consider factors such as latency of delivery of requested content in order to meet service level agreements or to generally improve the quality of delivery service.

Throughout the drawings, reference numbers may be re-used to indicate correspondence between referenced elements. The drawings are provided to illustrate example embodiments described herein and are not intended to limit the scope of the disclosure.

FIG. 1 is a block diagram of an illustrative operating environment in which a pattern-based request routing system may cause content requests to be routed to certain points of presence (POPs) based on identified user device content request patterns.

FIGS. 2A-2B are block diagrams of the operating environment of FIG. 1 illustrating the operations performed by the components of the operating environment of FIG. 1 to identify content request patterns from access logs and route content requests accordingly, according to one embodiment.

FIG. 3 is a block diagram of the operating environment of FIG. 1 illustrating the operations performed by the components of the operating environment of FIG. 1 to evict content from the cache data store of the CDN service implemented by one POP after a user device is re-routed to another POP, according to one embodiment.

FIG. 4 is a block diagram of the operating environment of FIG. 1 illustrating the operations performed by the components of the operating environment of FIG. 1 to identify time windows during which content should be served, according to one embodiment.

FIG. 5 is a flow diagram depicting a content request re-route routine illustratively implemented by a pattern-based request routing system, according to one embodiment.

A user device typically requests content resources (e.g., a data object, such as a video file, an audio file, a script, an image, a document, etc.) from a content delivery network (CDN) in response to a user providing an input indicating that the user would like to view a particular content page (e.g., a network page, a Web page, etc.). The CDN can then retrieve the requested content resources from a local cache and/or an origin server, and forward the retrieved content resources to the user device. This process, however, may result in a delay noticeable to the user. In particular, a few seconds may pass between when the user provides an input requesting to view a content page and when the user device has retrieved the appropriate content resources and is able to render and display the requested content page. In some cases, the delay may be long enough such that the user attempts to request another content page.

Thus, CDN service providers often consider factors such as latency of delivery of requested content in determining where to route content requests. For example, to reduce latency, a CDN service provider may route content request traffic to CDNs located geographically close to the source of the content request (e.g., a user device).

Relying solely on geography, however, can introduce various issues. For example, a CDN may initially retrieve requested content from an origin server in response to receiving a request for the content from a user device. The CDN may then cache the retrieved content such that the CDN can serve future requests for the content by retrieving the content from a local cache rather than from the origin server. Thus, a CDN's cache may store various content requested by various user device. The cache, however, has a certain cache width (e.g., a certain amount of memory available to store cached content), and therefore can only store a certain amount of data (e.g., 1 GB, 10 GB, 100 GB, 1 TB, etc.). If the cache is full and a user device submits a request for content not already stored in the cache, the CDN can evict some content from the cache (e.g., content in the cache that was least-recently requested by a user device) to make room in the cache for the newly requested content.

The cache eviction process can become problematic, negatively impacting content retrieval latency for one or more user devices, if one user device begins requesting byte-heavy content, such as large video files (e.g., files greater than 1 GB, 10 GB, 100 GB, 1 TB, etc.) or individual files that relate to the same content and are often requested in quick succession (e.g., files corresponding to streamed content; individual files that each form a portion of a larger file, such as a video file, an audio file, a software application, a software upgrade, etc.; etc.). In this situation, the requested content may take up a large portion of the cache. Thus, other content requested by other user devices may be evicted from the cache to make room in the cache for the byte-heavy content. User devices that attempt to retrieve the now-evicted content may experience higher content retrieval latency because the CDN may have to retrieve the now-evicted content from the origin server rather than from the cache.

Accordingly, a pattern-based content request routing system is described herein that can route content requests according to user and/or user device behavior. For example, the pattern-based content request routing system can cause requests for byte-heavy content to be routed to CDNs that have a sufficiently large cache width—even if such CDNs are not the geographically-closest CDNs to the source of the requests—to reduce the negative impact on content retrieval latency for other user devices that may be requesting other content. In particular, CDNs may store access logs or other data indicating the types of content requested by various user devices. The pattern-based content request routing system can retrieve the access logs in real-time (e.g., as an access log is created in response to a user device content request) and/or in near real-time (e.g., a threshold period of time, such as 10 seconds, 30 seconds, 1 minute, 5 minutes, etc., after an access log is created in response to a user device content request) and analyze the access logs to identify patterns of requests. Such patterns can include that a first user device is generally requesting small files (e.g., images, text documents, scripts, etc.), a second user device is generally requesting large files (e.g., a video file, a software application, a software update, etc.), a third user device is currently or generally requesting a large amount of files (either large or small in size) in quick succession (e.g., periodically every 10 seconds, 30 seconds, minute, 5 minutes, etc.; a threshold number of files within a threshold period of time; etc.), which may indicate that the third user device is streaming content and/or requesting individual files that each form a portion of a larger file, and so on.

The pattern-based content request routing system can then evaluate the cache capacity of various CDNs, and determine which CDNs may be suitable for the identified patterns of requests. For example, CDNs with a large cache width may be suitable for serving user devices that generally request large files or a large amount of files, whereas CDNs with a small cache width may be suitable for serving user devices that generally request small files. Based on this determination, the pattern-based content request routing system can instruct a DNS server to provide to user devices the addresses of CDNs that are suitable for handling the patterns of requests exhibited by the respective user devices.

Because requests for byte-heavy content can be routed to CDNs that have a large cache width due to the operations performed by the pattern-based content request routing system, content stored in the caches of CDNs with small cache widths are less likely to be evicted from the caches to make room in the caches for the byte-heavy content. The content retrieval latency for user devices that request content stored in the caches of CDNs with small cache widths may therefore be reduced. In fact, reduction of the content retrieval latency may also result in a reduction of a latency of the user device in rendering and displaying a content page given that content resources displayed in the content page may be retrieved at a faster rate.

The foregoing aspects and many of the attendant advantages of this disclosure will become more readily appreciated as the same become better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings.

Example Pattern-Based Request Routing Environment

FIG. 1 is a block diagram of an illustrative operating environment 100 in which a pattern-based request routing system 140 may cause content requests to be routed to certain points of presence (POPs) 120 based on identified user device 102 content request patterns. The operating environment 100 may further include one or more user devices 102 , one or more origin servers 104 , and one or more DNS servers 130 . The various user devices 102 may communicate with the POPs 120 via a network 110 to request content. The pattern-based request routing system 140 can communicate with the POPs 120 and/or the DNS servers 130 via the network 110 to provide the improved content requesting routing functionality described herein.

In some instances, a CDN may operate as a distributed system in which multiple POPs implement instances of the CDN. For example, each POP 120 may implement a CDN service 122 . As used herein, a POP is intended to refer to any collection of related computing devices utilized to implement functionality on behalf of one or many providers. POPs are generally associated with a specific geographic location in which the computing devices implementing the POP are located, or with a region serviced by the POP. For example, a data center or a collection of computing devices within a data center may form a POP. A CDN may utilize multiple POPs that are geographically diverse, to enable users in a variety of geographic locations to quickly transmit and receive information (e.g., requested content) from the CDN. In some instances, the POPs may also implement other services in addition to the CDN services, such as data storage services, data processing services, etc.

While the user devices 102 and POPs 120 are shown as grouped within FIG. 1 , the user devices 102 and POPs 120 may be geographically distant, and independently owned or operated. For example, the user devices 102 could represent a multitude of users in various global, continental, or regional locations accessing the POPs 120 . Further, the POPs 120 may be globally, continentally, or regionally disparate, in order to provide a wide geographical presence for the CDN services 122 . Accordingly, the groupings of user devices 102 and POPs 120 within FIG. 1 is intended to represent a logical, rather than physical, grouping.

The origin servers 104 may include any computing device owned or operated by an entity that has provided one or more sets of content (“distributions”) to a CDN (e.g., CDN service 122 ) for subsequent transmission to user devices 102 . For example, origin servers 104 may include servers hosting web sites, streaming audio, video, or multimedia services, data analytics services, or other network-accessible services. The origin servers 104 may include primary versions of content within various distributions. The primary versions of content may be retrieved by the various POPs 120 for subsequent transmission to the user devices 102 . In an embodiment, each POP 120 includes a cache that stores frequently-requested content (e.g., the cache data store 128 ). If requested content is not present in the POP 120 cache, then the POP 120 may retrieve the content from an origin server 104 . In alternate embodiments, not shown, the POP 120 may first request the content from an intermediate cache housed within a regional data center. If the requested content is also not present in the intermediate cache, then the POP 120 may retrieve the content from an origin server 104 .

Users, by way of user devices 102 , may interact with a CDN service 122 of a POP 120 to request content. A CDN service 122 may include an access logs data store 124 , one or more cache servers 126 , and the cache data store 128 . In an embodiment, the CDN service 122 may include a host (not shown) that selects a cache server 126 to deliver the requested content to the user device 102 . A single POP 120 may include multiple hosts such that the POP 120 can service multiple data object requests simultaneously.

A DNS server 130 may provide a user device 102 with a network address (e.g., Internet protocol (IP) address) corresponding to a host or domain name provided by the user device 102 . For example, a user operating the user device 102 may provide a host or domain name to access a content page or to otherwise retrieve content provided by a CDN. In order to identify a network address corresponding to the host or domain name, the user device 102 may submit a DNS query that identifies the host or domain name (or a content resource). The user device 102 may submit the DNS query to a DNS server 130 or to a DNS resolver (not shown) present between the user device 102 and a DNS server 130 that then forwards and/or relays the DNS query to the DNS server 130 . The DNS server 130 can then identify a network address corresponding to the host or domain name (or content resource) identified in the DNS query (e.g., by querying a lookup table or a similar data structure), and transmit a resolved DNS query to the user device 102 (optionally via the DNS resolver) that includes the corresponding network address. Here, the DNS server 130 may include a network address of a POP 120 in a resolved DNS query. The user device 102 can then communicate with the POP 120 to retrieve requested content.

Generally, the DNS server 130 may provide the user device 102 with a network address of a POP 120 that is located geographically close to the user device 102 . For example, the DNS server 130 may provide the user device 102 with a network address of a POP 120 that is in the same region as the user device 102 . By providing the user device 102 with a network address of a POP 120 that is located geographically close to the user device 102 , the DNS server 130 may help reduce the user device 102 content retrieval latency.

However, as described herein, providing a user device 102 with a network address of a POP 120 that is located geographically close to the user device 102 may not reduce the content retrieval latency for all user devices 102 that request content from the POP 120 . For example, if the user device 102 attempts to request a large file and/or a large number of files (e.g., 10 files, 100 files, 1000 files, etc.) in quick succession from the POP 120 , and the cache data store 128 of the CDN service 122 implemented by the POP 120 has a small or limited cache width, the cache data store 128 may begin evicting other content to make room for the requested file(s). Any user device 102 that then attempts to retrieve the now-evicted content may experience longer content retrieval times.

Thus, the pattern-based request routing system 140 can communicate with the DNS servers 130 and/or the POPs 120 to facilitate the re-routing of certain content requests to different POPs 120 , such as POPs 120 that may not necessarily be the closest POP 120 geographically to the user device 102 that submitted the content request. The pattern-based request routing system 140 may identify patterns of user and/or user device 102 behavior in determining how and/or when to re-route certain content requests. The pattern-based request routing system 140 may include various components, such as one or more access log analyzers 142 , one or more cache evictors 144 , and a POP data store 146 .

The access log analyzer 142 can retrieve access logs (or specific content within the access logs) from the access logs data store 124 of one or more CDN services 122 . The access logs data store 124 may store, in entries associated with specific users and/or user devices 102 , access logs indicating previous content pages and/or content (e.g., content metadata, such as content type, file format, file size, files related thereto, etc.) requested by the user and/or user device 102 , content pages visited by the user and/or user device 102 after requesting content for a specific content page, attributes of the user and/or user device 102 , a geographic region from which the user device 102 requested content pages and/or content, and/or the like. The access log analyzer 142 can retrieve the access logs in real-time (e.g., as an access log is created in response to a user device 102 content request) and/or in near real-time (e.g., a threshold period of time, such as 10 seconds, 30 seconds, 1 minute, 5 minutes, etc., after an access log is created in response to a user device 102 content request).

Once retrieved, the access log analyzer 142 can analyze the access logs to identify patterns of user and/or user device 102 behavior (e.g., one or more content request patterns associated with a user device 102 ). For example, a content request pattern may be that a first user device 102 is generally requesting small files (e.g., images, text documents, scripts, etc.), a second user device 102 is generally requesting large files (e.g., a video file, a software application, a software update, etc.), a third user device 102 is currently or generally requesting a large amount of files (either large or small in size) in quick succession (e.g., periodically every 10 seconds, 30 seconds, minute, 5 minutes, etc.; a threshold number of files within a threshold period of time; etc.), which may indicate that the third user device 102 is streaming content and/or requesting individual files that each form a portion of a larger file, and so on. In particular, the access log analyzer 142 may identify content metadata present in the access logs, where the content metadata indicates the type of content, the content file format, the content file size, etc. of content requested by the user device 102 previously. The access log analyzer 142 can then identify a content request pattern by comparing the content metadata for content requested by the user device 102 in the past and determining whether the requested content consistently (e.g., a majority of the requested content, two-thirds of the requested content, etc.) is a byte-heavy type of content (e.g., audio and/or visual media, a software application, a software update, etc.), is a byte-light type of content (e.g., an image, a document, a script, etc.), has a file format that corresponds to byte-heavy content (e.g., a video file format, such as .mp4, a software application file format, such as .exe, etc.), has a file format that corresponds to byte-light content (e.g., an image file format, such as .jpg, a document file format, such as .doc or .txt, a script file format, such as .js, etc.), has a file size above a threshold value (e.g., 100 MB, 1 GB, 10 GB, etc.), has a file size below a threshold value (e.g., 10 MB, 5 MB, 1 MB, etc.), and/or the like.

The access log analyzer 142 can also access the POP data store 146 to identify the characteristics of various POPs 120 and/or the CDN services 122 implemented therein. For example, the POP data store 146 may store POP data for various POPs 120 . The POP data for a POP 120 may include a network address of the POP 120 , a geographic region of the POP 120 , latency value(s) associated with the POP 120 (where each latency value may correspond to a particular geographic region), network jitter value(s) associated with the POP 120 (where each network jitter value may correspond to a particular geographic region), a cache width of the cache data store 128 included in the CDN service 122 implemented by the POP 120 (e.g., a capacity, in bytes, of the cache data store 128 included in the CDN service 122 implemented by the POP 120 ), a POP 120 classification (e.g., whether a POP 120 is classified as being capable of handling byte-heavy traffic or otherwise has been selected or classified as a POP 120 to handle byte-heavy traffic, whether a POP 120 is classified as being capable of handling small file requests or otherwise has been selected or classified as a POP 120 to handle small file requests, etc.), and/or the like.

The access log analyzer 142 can use the POP data to determine which POP 120 should receive content requests submitted by a particular user device 102 . For example, the access log analyzer 142 can identify a content request pattern associated with a user device 102 . The access log analyzer 142 can also identify a geographic region from which the user device 102 requests content using the retrieved access logs. The access log analyzer 142 can then use the POP data to identify a POP 120 that has characteristics that align with the content request pattern exhibited by the user device 102 .

For a user device 102 that consistently requests small files, the access log analyzer 142 may determine that a POP 120 closest geographically to the user device 102 , a POP 120 classified as handling small files, and/or a POP 120 that has the lowest latency value for the geographic region from which the user device 102 requests content is the best POP 120 to serve the user device 102 . Because the user device 102 consistently requests small files, the access log analyzer 142 may not consider cache data store 128 cache width in making the determination. The access log analyzer 142 can then obtain the network address of the determined best POP 120 from the POP data, and instruct a DNS server 130 to provide the network address of the determined best POP 120 to the user device 102 in response to the user device 102 submitting a DNS query. Alternatively or in addition, the DNS server 130 can periodically query the access log analyzer 142 to determine which network address to provide to the user device 102 in response to the user device 102 submitting a DNS query.

For a user device 102 that consistently requests large files, the access log analyzer 142 may determine that a POP 120 that implements a CDN service 122 that has a cache data store 128 with a large cache width (e.g., a cache width greater than a threshold value, such as 1 TB, 10 TB, 100 TB, etc.) and/or a POP 120 that is classified as handling byte-heavy traffic is the best POP 120 to service the user device 102 . The access log analyzer 142 may select a POP 120 with a large cache width and/or that is classified as handling byte-heavy traffic that is the closest geographically to the user device 102 . However, the determined best POP 120 may not necessarily be the closest POP 120 geographically to the user device 102 . For example, another POP 120 may be closer geographically to the user device 102 , but this POP 120 may have a small cache width (e.g., a cache width less than a threshold value, such as 1 TB, 10 TB, 100 TB, etc.) and/or classified as handling small files and therefore is not selected as the best POP 120 to serve the user device 102 . For certain large files, such as video files, the effects of an increased content retrieval latency resulting from directing the user device 102 to a farther POP 120 can be minimized by a media client running on the user device 102 , which can pre-request additional content to ensure that media playback remains continuous. In fact, for certain large files, such as video files, network jitter may be a bigger concern than content retrieval latency. Having low network jitter values may ensure that media playback remains continuous. Thus, the access log analyzer 142 may optionally consider POP 120 network jitter values, selecting the POP 120 with a large cache width and/or the lowest network jitter value for the geographic region from which the user device 102 requests content. The access log analyzer 142 can then obtain the network address of the determined best POP 120 from the POP data, and instruct a DNS server 130 to provide the network address of the determined best POP 120 to the user device 102 in response to the user device 102 submitting a DNS query. Alternatively or in addition, the DNS server 130 can periodically query the access log analyzer 142 to determine which network address to provide to the user device 102 in response to the user device 102 submitting a DNS query.

For a user device 102 that is currently requesting and/or consistently requests a large number of files in quick succession, the access log analyzer 142 may determine that a POP 120 that implements a CDN service 122 that has a cache data store 128 with a large cache width (e.g., a cache width greater than a threshold value, such as 1 TB, 10 TB, 100 TB, etc.) and/or a POP 120 that is classified as handling byte-heavy traffic is the best POP 120 to service the user device 102 . The access log analyzer 142 may select a POP 120 with a large cache width and/or that is classified as handling byte-heavy traffic that is the closest geographically to the user device 102 . However, the determined best POP 120 may not necessarily be the closest POP 120 geographically to the user device 102 . For example, another POP 120 may be closer geographically to the user device 102 , but this POP 120 may have a small cache width (e.g., a cache width less than a threshold value, such as 1 TB, 10 TB, 100 TB, etc.) and/or classified as handling small files and therefore is not selected as the best POP 120 to serve the user device 102 . For certain files, such as video files, the effects of an increased content retrieval latency resulting from directing the user device 102 to a farther POP 120 can be minimized by a media client running on the user device 102 , which can pre-request additional content to ensure that media playback remains continuous. In fact, for certain files, such as video files, network jitter may be a bigger concern than content retrieval latency. Having low network jitter values may ensure that media playback remains continuous. Thus, the access log analyzer 142 may optionally consider POP 120 network jitter values, selecting the POP 120 with a large cache width and/or the lowest network jitter value for the geographic region from which the user device 102 requests content. The access log analyzer 142 can then obtain the network address of the determined best POP 120 from the POP data, and instruct a DNS server 130 to provide the network address of the determined best POP 120 to the user device 102 in response to the user device 102 submitting a DNS query. Alternatively or in addition, the DNS server 130 can periodically query the access log analyzer 142 to determine which network address to provide to the user device 102 in response to the user device 102 submitting a DNS query.

The number of access logs and/or the number of previous content page and/or content requests that the access log analyzer 142 analyzes before identifying a content request pattern and instructing the DNS server 130 to route a user device 102 that requests large files and/or a large number of files in quick succession to a different POP 120 can depend on one or more factors. For example, the access log analyzer 142 may instruct the DNS server 130 to route the user device 102 to a different POP 120 if the previously requested content takes up a threshold amount of space (e.g., a percentage, such as 10%, 20%, etc.; a value, such as 10 GB, 100 GB, 1 TB, etc.; etc.) in the cache data store 128 of the CDN service 122 implemented by the origin POP 120 . Alternatively or in addition, the access log analyzer 142 may instruct the DNS server 130 to route the user device 102 to a different POP 120 if the user device 102 has previously requested a threshold number of files (e.g., 5 files, 10 files, 50 files, 100 files, etc.) within a certain period of time.

In some cases, the user device 102 that consistently requests large files, that is currently requesting a large number of files in quick succession, and/or that consistently requests a large number of files in quick succession may initially have been routed by the DNS server 130 to a first POP 120 with a small cache width. After the access log analyzer 142 performs the operations described herein, the DNS server 130 may begin routing the user device 102 to a second POP 120 with a larger cache width. A cache server 126 of the CDN service 122 implemented by the first POP 120 may have cached the initial content requested by the user device 102 . However, now that the user device 102 is being routed to the second POP 120 , the initially cached content may no longer be requested by the user device 102 and/or other user devices 102 . Thus, the access log analyzer 142 can notify the cache evictor 144 when a user device 102 is being routed to a different POP 120 . The cache evictor 144 can then instruct the original POP 120 (e.g., the first POP 120 in the example above) to evict, from the cache data store 128 , at least some of the content initially requested by the user device 102 . In particular, the cache evictor 144 may instruct a cache server 126 in the CDN service 122 implemented by the original POP 120 to evict, from the cache data store 128 , at least some of the content initially requested by the user device 102 . This may prevent other content that may otherwise be requested by one or more user devices 102 from being evicted from the cache data store 128 prior to the content initially requested by the user device 102 being evicted (where the content initially requested by the user device 102 can be evicted first, even if the content is not the least-recently requested content stored in the cache data store 128 , because the content will no longer be requested), and frees up additional space for other content to be stored in the cache data store 128 .

The pattern-based request routing system 140 may include a single cache evictor 144 , and therefore the single cache evictor 144 may be configured to instruct a single POP 120 or multiple POPs 120 to evict content from cache. Alternatively, the pattern-based request routing system 140 may include multiple cache evictors 144 . Each cache evictor 144 may be associated with a single POP 120 or with multiple POPs 120 . Thus, each cache evictor 144 may be configured to instruct one POP 120 or multiple POPs 120 to evict content from cache. In some embodiments, two or more cache evictors 144 may be associated with the same POP 120 , and therefore any of these cache evictors 144 can be configured to instruct the POP 120 to evict content from cache.

In further embodiments, the CDN services 122 (e.g., the cache servers 126 ) can track which content has been evicted from the corresponding cache data store 128 over a period of time. If the cache evictor 144 instructs a cache server 126 to evict content previously requested by a user device 102 , thereby indicating that the user device 102 and/or other user devices 102 will no longer be requesting the content, the cache server 126 can retrieve, from one or more origin servers 104 , the content initially evicted from the cache data store 128 to make room for the content requested by the user device 102 that the cache evictor 144 is now indicating should be evicted. Thus, the cache server 126 can effectively restore the cache data store 128 to a time before the user device 102 began requesting content that the cache evictor 144 is now indicating should be evicted.

As an illustrative example, a first user device 102 may provide a host or domain name to a DNS server 130 in a DNS query for ultimately requesting a first file. In response, the DNS server 130 may provide the first user device 102 with a network address of a first POP 120 . The user device 102 may then request the first file from the first POP 120 . The first file may be a first portion of a movie. The first user device 102 may then repeat these steps, requesting a second file from the first POP 120 shortly after requesting the first file. The second file may be a second portion of the movie. The first user device 102 may continue periodically requesting 8 additional files corresponding to successive portions of the movie. In real-time or near real-time, the access log analyzer 142 may retrieve and analyze access logs corresponding to these 10 file requests submitted by the first user device 102 . The access log analyzer 142 may ultimately identify a content request pattern for the first user device 102 . Specifically, the access log analyzer 142 may determine that the first user device 102 is requesting movie files (e.g., individual movie files that each form a portion of a larger movie file and/or that each correspond to the same movie) in quick succession. In addition, the access log analyzer 142 may recognize that the first POP 120 implements a first CDN service 122 with a cache data store 128 that has a small or limited cache width. Accordingly, the access log analyzer 142 instructs a DNS server 130 to begin providing the first user device 102 with a network address of a second POP 120 that implements a second CDN service 122 with a cache data store 128 having a large cache width in response to the first user device 102 submitting a DNS query. As a result, the first user device 102 may request an eleventh file corresponding to an eleventh portion of the movie from the second POP 120 . Because the cache data store 128 of the first CDN service 122 may include cached versions of the first 10 files requested by the first user device 102 , the cache evictor 144 can instruct a cache server 126 of the first CDN service 122 to evict these 10 files from the cache data store 128 of the first CDN service 122 . Thus, the cache server 126 of the first CDN service 122 may not have to immediately evict other content from the cache data store 128 in response to receiving future content requests from other user devices 102 .

The access log analyzer 142 can also retrieve access logs from the access logs data stores 124 of one or more CDN services 122 to determine time windows (e.g., in seconds, minutes, hours, days, weeks, months, years, etc.) in which POPs 120 have high traffic levels and/or time windows in which POPs 120 have low traffic levels. The access log analyzer 142 can use this information to instruct POPs 120 to serve content requests during certain time windows, such as time windows during which traffic levels are otherwise low. By serving content requests during time windows in which traffic levels are low, POPs 120 may have the processing capacity to process and serve content requests quickly, causing user devices 102 to experience lower content retrieval times than if the content requests are processed and served during high traffic periods.

For example, the access log analyzer 142 can retrieve the access logs and determine, for a given POP 120 , a time window during which the traffic handled by the respective POP 120 is at a lowest level. The access log analyzer 142 can determine a time window during which the traffic handled by the respective POP 120 is at a lowest level by, for example, identifying the number of content requests received by the respective POP 120 at various time periods (e.g., seconds, minutes, hours, days, weeks, months, years, etc.) using the access logs and identifying a time period in which the number of content requests received is at a lowest number.

The access log analyzer 142 can then instruct a CDN service 122 (e.g., a cache server 126 ) implemented by the respective POP 120 to serve content requests during the time window in which the traffic handled by the respective POP 120 is at a lowest level. In an embodiment, the access log analyzer 142 can limit the instruction to specified content and/or specified types of content (e.g., a particular video file, a particular software application, a particular software update, etc.) such that the respective POP 120 would only serve the specified content or specified types of content during the determined time window and/or would only begin serving the specified content or specified types of content during the determined time window. If a user device 102 then transmits a content request to the respective POP 120 outside of the determined time window, and the request is for content that is to be served during the time window, the CDN service 122 (e.g., cache server 126 ) implemented by the respective POP 120 can respond to the request by indicating that the requested content is unavailable, the requested content cannot be located, the requested content will be available at a later, specified time, and/or the like. On the other hand, if a user device 102 transmits a content request to the respective POP 120 during the determined time window, and the request is for content that is to be served during the time window, the CDN service 122 (e.g., cache server 126 ) implemented by the respective POP 120 can retrieve and provide to the user device 102 the requested content.

As an illustrative example, a user device 102 may attempt to retrieve a software upgrade or patch from a POP 120 at 7:00 pm. The access log analyzer 142 may have determined, however, that traffic levels at 7:00 pm are high or are otherwise not at the lowest levels, and may have instructed the POP 120 to not serve the software upgrade or patch between 7:00 am and 12:59 am. Rather, the access log analyzer 142 may have instructed the POP 120 to begin serving the software upgrade or patch at 1:00 am—a time at which traffic levels are low and/or are at the lowest level (as compared to other times of the day, week, month, year, etc.). While the software upgrade or patch may be available in the cache data store 128 of the CDN service 122 implemented by the POP 120 and/or in an origin server 104 , the POP 120 may nonetheless indicate that the software upgrade or patch is unavailable in response to the request received from the user device 102 at 7:00 pm. Optionally, the POP 120 may provide the user device 102 with a time or time window during which the software upgrade or patch may be available (e.g., 1:00 am). If the user device 102 then attempts to retrieve the software upgrade or patch at 2:00 am, the POP 120 may retrieve and provide to the user device 102 the software upgrade or patch.

In further embodiments, the access log analyzer 142 can perform an analysis to determine whether a user device 102 requesting content from a first POP 120 local to the user device 102 during a time window in which the traffic handled by the first POP 120 is not at a lowest level (and/or is at a level above a threshold value) should be redirected to a second POP 120 that may be farther away than the first POP 120 (e.g., in a different geographic region than the user device 102 ) but that is currently handling traffic at a lowest level. For example, the first POP 120 local to the user device 102 may indicate that the requested content is not yet available. However, the content may be available from the second POP 120 because the access log analyzer 142 had already instructed the second POP 120 to serve the requested content during a current time window. The access log analyzer 142 can evaluate the performance cost (e.g., increased latency, degraded level of performance perceived by the user, etc.) that results from directing the user device 102 to a farther POP 120 versus the performance cost (e.g., increased latency) that results from having the user device 102 wait for the local POP 120 to serve the requested content during a high traffic period. The access log analyzer 142 can factor current, absolute traffic levels at the local and farther POPs 120 in evaluating the performance costs and the tradeoff between routing a user device 102 to a local or farther POP 120 (e.g., increased traffic levels at the farther POP 120 , even if relatively low, may negate any benefits that may have been achieved by routing the user device 102 to the farther POP 120 ). If the performance cost for directing the user device 102 to a farther POP 120 is less than the performance cost of having the user device 102 wait for the local POP 120 to serve the requested content, the access log analyzer 142 can instruct the DNS server 130 to provide the network address of the farther POP 120 in response to the user device 102 submitting a DNS query.

As an illustrative example, the user device 102 may reside in the state of Washington and may attempt to retrieve content from a first POP 120 within Washington state. The user device 102 , however, may attempt to retrieve the content at 10:00 pm, a high traffic time for the first POP 120 . A second POP 120 in the state of Florida, however, may be handling a low number of requests because it is 1:00 am and a larger number of users are offline. If the access log analyzer 142 determines that the performance costs of routing the user device 102 to the second POP 120 are less than the performance costs of allowing the user device 102 to wait for the first POP 120 to respond (e.g., the latency involved in routing a user device 102 in Washington to a second POP 120 in Florida is less than the latency involved in allowing a user device 102 to wait for the first POP 120 in Washington state to respond), the access log analyzer 142 may cause the DNS server 130 to route the user device 102 to the second POP 120 in Florida.

A single access log analyzer 142 or multiple access log analyzers 142 may be present in the environment 100 . If multiple access log analyzers 142 are present, each access log analyzer 142 may be associated with a particular geographic region that includes one or more POPs 120 . The access log analyzer 142 of a particular geographic region can reside on the POP 120 of that region or can reside within the geographic region on a computing device separate from the POP 120 .

As described herein, each POP 120 is a collection of related computing devices utilized to implement CDN functionality on behalf of one or many providers. For example, the access logs data store 124 , the one or more cache servers 126 , and/or the cache data store 128 may each be implemented by one or more related computing devices (e.g., devices that include one or more processors, memory, input/output interfaces, networking interfaces, etc. to implement the functionality described herein). Each POP 120 may be generally associated with a specific geographic location in which the computing devices implementing the respective POP 120 are located, or with a region serviced by the respective POP 120 . For example, a data center or a collection of computing devices within a data center may form a POP 120 . A CDN may utilize multiple POPs 120 that are geographically diverse, to enable users in a variety of geographic locations to quickly transmit and receive information (e.g., requested data objects) from the CDN. In some instances, the POPs 120 may also implement other services in addition to the CDN services 122 , such as data storage services, data processing services, etc.

The CDN services 122 may operate in a distributed computing environment including several computer systems that are interconnected using one or more computer networks (not shown in FIG. 1 ). The CDN services 122 could also operate within a computing environment having a fewer or greater number of devices than are illustrated in FIG. 1 . For example, the CDN services 122 are depicted as including an access logs data store 124 , one or more cache servers 126 , and a cache data store 128 , but the access logs data store 124 , the one or more cache servers 126 , and/or the cache data store 128 may be implemented by computing devices located external to the POPs 120 . Thus, the depiction of the CDN services 122 in FIG. 1 should be taken as illustrative and not limiting to the present disclosure. For example, the CDN services 122 or various constituents thereof could implement various Web services components, hosted or “cloud” computing environments, and/or peer to peer network configurations to implement at least a portion of the processes described herein. Further, the CDN services 122 may be implemented directly in hardware or software executed by hardware devices and may, for instance, include one or more physical or virtual servers implemented on physical computer hardware configured to execute computer executable instructions for performing various features that are described herein.

While the access logs data store 124 is depicted as being internal to the CDN service 122 , this is not meant to be limiting. For example, the access logs data store 124 can be located external to the CDN service 122 (e.g., within the POP 120 , external to the POP 120 , etc.).

The pattern-based request routing system 140 may be a single computing device, or may include multiple distinct computing devices, such as computer servers, logically or physically grouped together to collectively operate as a server system. The components of the pattern-based request routing system 140 can be implemented in application-specific hardware (e.g., a server computing device with one or more ASICs) such that no software is necessary, or as a combination of hardware and software. In addition, the modules and components of the pattern-based request routing system 140 can be combined on one server computing device or separated individually or into groups on several server computing devices. In some embodiments, the pattern-based request routing system 140 may include additional or fewer components than illustrated in FIG. 1 .

The pattern-based request routing system 140 may be located external to the POPs 120 and/or the DNS servers 130 such that a single pattern-based request routing system 140 can analyze access logs and cause pattern-based routing of content requests. However, in other embodiments, not shown, the pattern-based request routing system 140 may be internal to a POP 120 . In still other embodiments, not shown, the pattern-based request routing system 140 may be internal to a DNS server 130 .

While the POP data store 146 is depicted as being internal to the pattern-based request routing system 140 , this is not meant to be limiting. For example, the POP data store 146 can be located external to the pattern-based request routing system 140 .

Various example user devices 102 are shown in FIG. 1 , including a desktop computer, laptop, and a mobile phone, each provided by way of illustration. In general, the user devices 102 can be any computing device such as a desktop, laptop or tablet computer, personal computer, wearable computer, server, personal digital assistant (PDA), hybrid PDA/mobile phone, mobile phone, electronic book reader, set-top box, voice command device, camera, digital media player, and the like. A user device 102 may execute an application (e.g., a browser) that submits requests for content pages and/or other content to the POPs 120 when, for example, a user attempts to view a content page (e.g., a network page, a Web page, etc.).

The network 110 may include any wired network, wireless network, or combination thereof. For example, the network 110 may be a personal area network, local area network, wide area network, over-the-air broadcast network (e.g., for radio or television), cable network, satellite network, cellular telephone network, or combination thereof. As a further example, the network 110 may be a publicly accessible network of linked networks, possibly operated by various distinct parties, such as the Internet. In some embodiments, the network 110 may be a private or semi-private network, such as a corporate or university intranet. The network 110 may include one or more wireless networks, such as a Global System for Mobile Communications (GSM) network, a Code Division Multiple Access (CDMA) network, a Long Term Evolution (LTE) network, or any other type of wireless network. The network 110 can use protocols and components for communicating via the Internet or any of the other aforementioned types of networks. For example, the protocols used by the network 110 may include Hypertext Transfer Protocol (HTTP), HTTP Secure (HTTPS), Message Queue Telemetry Transport (MQTT), Constrained Application Protocol (CoAP), and the like. Protocols and components for communicating via the Internet or any of the other aforementioned types of communication networks are well known to those skilled in the art and, thus, are not described in more detail herein.

FIGS. 2A-2B are block diagrams of the operating environment 100 of FIG. 1 illustrating the operations performed by the components of the operating environment 100 to identify content request patterns from access logs and route content requests accordingly, according to one embodiment. As illustrated in FIG. 2A , the user device 102 transmits a DNS query to the DNS server 130 at ( 1 ). Optionally, the DNS query may be transmitted to the DNS server 130 via a DNS resolver (not shown). The DNS query may include a host or domain name that the user device 102 is attempting to access.

The DNS server 130 can then transmit a resolved DNS query identifying an address of POP 120 A to the user device 102 at ( 2 ). For example, the DNS server 130 may identify a geographic region from which the user device 102 DNS query originated, determine that the POP 120 A is the closest POP to the identified geographic region, and return to the user device 102 a network address of the POP 120 A in response.

The user device 102 can use the address included in the resolved DNS query to request a content resource from cache server 126 A of a CDN service 122 A implemented by the POP 120 A at ( 3 ). Here, the requested content resource may not be stored locally, such as in cache data store 128 A. Thus, the cache server 126 A can request the content resource from the origin server 104 at ( 4 ). The origin server 104 can then transmit the content resource to the cache server 126 A at ( 5 ) to satisfy the request. In other embodiments, not shown, the requested content resource may be stored locally, such as in the cache data store 128 A. Thus, the cache server 126 A can simply retrieve the requested content resource from the cache data store 128 A instead of the origin server 104 .

Once retrieved from the origin server 104 , the cache server 126 A can store the content resource in the cache data store 128 A at ( 6 ). Thus, the cache server 126 A can retrieve the content resource from the cache data store 128 A instead of the origin server 104 the next time the content resource is requested. Before, during, and/or after storing the content resource in the cache data store 128 A, the cache server 126 A store an access log in the access logs data store 124 at ( 7 ). The access log may include information identifying which content resource the user device 102 requested, content metadata corresponding to the content resource, a geographic region from which the user device 102 requested the content resource, and/or the like. Before, during, and/or after storing the content resource in the cache data store 128 A and/or storing the access log in the access logs data store 124 , the cache server 126 A can transmit the content resource to the user device 102 at ( 8 ) to satisfy the user device 102 request.

As illustrated in FIG. 2B , the access log analyzer 142 can retrieve access log(s) from the access logs data store 124 at ( 9 ). The access log analyzer 142 can retrieve the access log(s) in real-time (e.g., as the access logs are generated and/or stored) and/or in near real-time (e.g., soon after the access logs are generated and/or stored). The access log analyzer 142 can retrieve the access log(s) asynchronously from actions performed by the cache server 126 A (e.g., actions performed by the cache server 126 A to store access logs).

The access log analyzer 142 can determine that user device 102 is requesting content having a large size at ( 10 ) based on an analysis of the retrieved access logs. For example, the access log analyzer 142 may make this determination based on the content metadata in the access log(s). The access log analyzer 142 may determine that the user device 102 generally requests large content and/or is currently requesting content in quick succession. In response, the access log analyzer 142 can retrieve POP data from the POP data store 146 at ( 11 ) to determine whether the POP 120 A has sufficient cache capacity to handle user device 102 requests and, if not, which POP 120 may be a better alternative (e.g., an alternative that, on the whole, evicts fewer content resources when servicing the user device 102 , thereby improving the overall content retrieval latency when considering all user devices 102 ). Here, the access log analyzer 142 determines that the POP 120 A does not have the cache capacity to handle the content requested by the user device 102 . However, the access log analyzer 142 determines that POP 120 B has a cache capacity to handle the content requested by the user device 102 at ( 12 ) based on an analysis of the POP data and/or the access log(s). For example, while POP 120 A may be closer geographically to the user device 102 than the POP 120 B, the POP 120 B may implement a CDN service 122 B with a cache data store 126 B that has a larger cache width than the cache data store 126 A.

The access log analyzer 142 can then instruct the DNS server 130 to re-route the user device 102 to the POP 120 B at ( 13 ) in response to future DNS queries. In particular, the access log analyzer 142 can instruct the DNS server 130 to resolve DNS queries submitted by the user device 102 by providing a network address of the POP 120 B instead of a network address of the POP 120 A. The DNS server 130 can be instructed to resolve all DNS queries submitted by the user device 102 by providing the POP 120 B network address or the DNS 130 can be instructed to resolve DNS queries submitted by the user device 102 that are directed to a specific host or domain name (e.g., the same host or domain name that resulted in the user device 102 retrieving the content having the large size) by providing the POP 120 B network address. Alternatively or in addition, the DNS server 130 can periodically query the access log analyzer 142 to determine to which POP 120 the user device 102 should be routed in response to future DNS queries.

At a later time, the user device 102 may transmit a second DNS query to the DNS server 130 at ( 14 ). For example, the second DNS query may include any host or domain name or the same host or domain name as included in the first DNS query described above with respect to FIG. 2A . The user device 102 may have transmitted the first DNS query described above with respect to FIG. 2A to retrieve a file portion of a video file, and the user device 102 may transmit the second DNS query to retrieve the next portion of the video file. In response, the DNS server 130 can transmit to the user device 102 a second resolved DNS query identifying an address (e.g., the network address) of the POP 120 B at ( 15 ).

The user device 102 can use the address included in the second resolved DNS query to request a content resource from the POP 120 B (e.g., a cache server 126 B of a CDN service 122 B implemented by the POP 120 B) at ( 16 ). Here, the requested content resource may not be stored locally, such as in a cache data store 128 B of the CDN service 122 B. Thus, the POP 120 B (e.g., the cache server 126 B) can request the content resource from the origin server 104 at ( 17 ). The origin server 104 can then transmit the content resource to the POP 120 B (e.g., the cache server 126 B) at ( 18 ) to satisfy the request. In other embodiments, not shown, the requested content resource may be stored locally, such as in the cache data store 128 B. Thus, the POP 120 B (e.g., the cache server 126 B) can simply retrieve the requested content resource from the cache data store 128 B instead of from the origin server 104 .

Once retrieved from the origin server 104 , the POP 120 B (e.g., the cache server 126 B) can transmit the content resource to the user device 102 at ( 19 ) to satisfy the user device 102 request. Before, during, and/or after transmitting the content resource to the user device 102 , the POP 120 B (e.g., the cache server 126 B) can store the content resource in the cache data store 128 B. Thus, the POP 120 B (e.g., the cache server 126 B) can retrieve the content resource from the cache data store 128 B instead of from the origin server 104 the next time the content resource is requested.

Thus, the user device 102 may have initially retrieved content from the POP 120 A (e.g., the cache server 126 A). However, because the access log analyzer 142 determined that the user device 102 was requesting content having a large size (e.g., either as a general pattern or while requesting content in quick succession) and that the POP 120 B (e.g., the cache server 126 B) was best positioned to handle such pattern of content requests, the user device 102 began retrieving content from the POP 120 B (e.g., the cache server 126 B) instead of from the POP 120 A (e.g., the cache server 126 A) at the direction of the DNS server 130 . In some instances, the user device 102 may be retrieving related content (e.g., individual files that each form a portion of a media resource, such as a video, audio, etc.; individual files that each form a portion of a software application; individual files that each form a portion of a software upgrade or patch; etc.), and therefore the user device 102 may retrieve a portion of the related content from one POP 120 and another portion of the related content from another POP 120 . The re-routing of the user device 102 as the user device 102 is requesting content can prevent the user device 102 content requests from further negatively impacting cache performance on the POP 120 from which the user device 102 is re-routed.

While FIGS. 2A-2B depict a sequence of operations occurring in a numbered order, this is not meant to be limiting. Some or all of the operations described above with respect to FIGS. 2A-2B can be performed in a different order than shown. For example, while FIG. 2B depicts the access log analyzer 142 determining that the user device 102 is requesting content having a large size before retrieving POP data from the POP data store 146 , the access log analyzer 142 can retrieve the POP data from the POP data store 146 prior to making the determination.

FIG. 3 is a block diagram of the operating environment 100 of FIG. 1 illustrating the operations performed by the components of the operating environment 100 to evict content from the cache data store 128 of the CDN service 122 implemented by one POP 120 (e.g., the POP 120 A) after a user device 102 is re-routed to another POP 120 (e.g., the POP 120 B), according to one embodiment. As illustrated in FIG. 3 , the access log analyzer 142 retrieves access log(s) from the access logs data store 124 at ( 1 ). The access log analyzer 142 then determines that the POP 120 B and not the POP 120 A should receive requests for first content at ( 2 ). For example, the access log analyzer 142 can make the determination as described above with respect to FIG. 2B .

In response to making the determination, the access log analyzer 142 can instruct the DNS server 130 to re-route DNS queries directed to the first content to the POP 120 B instead of the POP 120 A at ( 3 ). For example, the access log analyzer 142 can instruct the DNS server 130 as described above with respect to FIG. 2B . Before, during, and/or after instructing the DNS server 130 , the access log analyzer 142 can transmit an indication to the cache evictor 144 that the POP 120 A will no longer receive requests for the first content at ( 4 ).

The cache evictor 144 can then transmit to the cache server 126 A an instruction to evict the first content from cache at ( 5 ). The cache server 126 A can then evict the first content from the cache data store 128 A at ( 6 ). Thus, the cache data store 128 A may no longer store the first content, which may be a large file or an individual file that forms a part of a large file (e.g., a video, audio, software application, software upgrade, etc.). The cache data store 128 A then may not have to evict as quickly content already stored in the cache data store 128 A (which may be requested by user devices 102 in the future) given that the cache data store 128 A now has additional memory space to store new content retrieved from an origin server 104 . This may reduce, on the whole, the content retrieval times experienced by user devices 102 that retrieve content from the POP 120 A.

In further embodiments, not shown, the cache server 126 A can track which content was evicted from the cache data store 128 A to make room for the first content. After the first content is evicted from the cache data store 128 A, the cache sever 126 A can retrieve the previously evicted content from an origin server 104 and store the previously evicted content back in the cache data store 128 A. Thus, the cache data store 128 A may effectively be restored to a state before a request for the first content was first received. The negative impact (e.g., increased content retrieval times) on the POP 120 A caused by retrieving byte-heavy content, such as the first content, can then be minimized.

While FIG. 3 depicts a sequence of operations occurring in a numbered order, this is not meant to be limiting. Some or all of the operations described above with respect to FIG. 3 can be performed in a different order than shown. For example, while FIG. 3 depicts the cache server 126 A evicting first content after the access log analyzer 142 instructs the DNS server 130 , the cache server 126 A can evict the first content prior to the access log analyzer 142 instructing the DNS server 130 .

FIG. 4 is a block diagram of the operating environment 100 of FIG. 1 illustrating the operations performed by the components of the operating environment 100 to identify time windows during which content should be served, according to one embodiment. As illustrated in FIG. 4 , the access log analyzer 142 can retrieve access log(s) at ( 1 ) from the access logs data store 124 .

The access log analyzer 142 can then determine that POP 120 A has a lowest traffic level during a first time window (e.g., in seconds, hours, days, weeks, months, years, etc.) at ( 2 ) based on an analysis of the access log(s). For example, the access log(s) may indicate that the POP 120 A receives a fewest number of content requests during the first time window. Alternatively or in addition, the access log(s) may indicate that the content requests received by the POP 120 A during the first time window are generally directed to small files that can be retrieved more quickly than files requested during other time windows.

The access log analyzer 142 can then instruct the POP 120 A to serve first content during (and/or after) the first time window at ( 3 ). For example, the access log analyzer 142 may instruct a cache server 126 A of a CDN service 122 A implemented by the POP 120 A to serve the first content during (and/or after) the first time window. The first content may be a large file, such as a video file, an audio file, a software application, a software upgrade or patch, etc., and therefore it may be desirable to serve the first content during low traffic times such that content retrieval times experienced by user devices 102 is minimized.

At a later time, the user device 102 can transmit a DNS query to the DNS server 130 at ( 4 ), optionally via a DNS resolver (not shown). In response, the DNS server 130 can transmit to the user device 102 a resolved DNS query identifying an address of the POP 120 A at ( 5 ).

The user device 102 may then request from the cache server 126 A the first content during a second time window at ( 6 ) using the provided POP 120 A address. The second time window may be before (or after) the first time window, and may correspond to times during which traffic levels at the POP 120 A are high (e.g., the number of requests received per time period (e.g., second, minute, hour, etc.) is above a threshold value). However, because the request for the first content is submitted during the second time window and not during (and/or after) the first time window, the cache server 126 A may respond to the request by transmitting to the user device 102 an indication that the first content is not available at ( 7 ). The cache server 126 A may transmit this request even if the first content is available in the cache data store 128 A of the CDN service 122 A and/or in an origin server 104 . Optionally, the cache server 126 A may indicate a time during which the first content will be available (e.g., the first time window).

The user device 102 may then transmit to the cache server 126 A another request for the first content at ( 8 ), this time during the first time window. Because traffic levels at the POP 120 A are low during the first time window (e.g., the number of requests received per time period (e.g., second, minute, hour, etc.) is below a threshold value) as determined by the access log analyzer 142 and the access log analyzer 142 has instructed the cache server 126 A to serve the first content only during (and/or after) the first time window, the cache server 126 A can respond to the request by either retrieving the first content from the cache data store 128 A at ( 9 ) (e.g., if the first content is already stored in the cache data store 128 A) or by retrieving the first content from the origin server 104 at ( 10 ) (e.g., if the first content is not already stored in the cache data store 128 A). The cache server 126 A can then transmit the retrieved first content to the user device 102 at ( 11 ) to satisfy the request. Thus, the access log analyzer 142 can minimize content retrieval times experienced by user devices 102 by controlling when POPs 120 serve certain content.

While FIG. 4 depicts a sequence of operations occurring in a numbered order, this is not meant to be limiting. Some or all of the operations described above with respect to FIG. 4 can be performed in a different order than shown. For example, while FIG. 4 depicts the user device 102 transmitting the DNS query after the access log analyzer 142 instructs POP 120 A to serve first content during (and/or after) the first time window, the user device 102 can transmit the DNS query before the access log analyzer 142 instructs POP 120 A to serve first content during (and/or after) the first time window.

Example Content Request Re-Route Routine

FIG. 5 is a flow diagram depicting a content request re-route routine 500 illustratively implemented by a pattern-based request routing system, according to one embodiment. As an example, the pattern-based request routing system (e.g., the access log analyzer 142 ) of FIG. 1 can be configured to execute the content request re-route routine 500 . The content request re-route routine 500 begins at block 502 .

At block 504 , access logs are retrieved. For example, the access logs may include content metadata.

At block 506 , a user device is determined to have requested content larger than a threshold size. For example, the access log analyzer 142 may determine, based on an analysis of the access logs, that the user device has requested, generally requests, and/or is currently requesting content larger than a threshold size. Alternatively or in addition, the access log analyzer 142 may determine, based on an analysis of the access logs, that the user device is requesting in quick succession individual files that form a portion of a larger file, such as a video file, an audio file, a software application, a software upgrade or patch, etc.

At block 508 , POP data is retrieved. The POP data may indicate, for example, the cache widths of cache data stores 128 of various POPs 120 .

At block 510 , a first POP is determined to have cache capacity to handle the content requested by the user device. For example, the first POP may have a cache width greater than a threshold value (e.g., 50% greater than the size of content generally requested by the user device, greater than 100 TB, etc.). The determination may be performed using the retrieved POP data.

At block 512 , a DNS server is instructed to route the user device to the first POP. Thus, the user device may begin retrieving content from the first POP, which is more capable of caching large content files than another POP from which the user device may have initially been requesting content (e.g., another POP that is geographically closer to the user device than the first POP). After instructing the DNS server, the content request re-route routine 500 is complete, as shown at block 514 .

All of the methods and tasks described herein may be performed and fully automated by a computer system. The computer system may, in some cases, include multiple distinct computers or computing devices (e.g., physical servers, workstations, storage arrays, cloud computing resources, etc.) that communicate and interoperate over a network to perform the described functions. Each such computing device typically includes a processor (or multiple processors) that executes program instructions or modules stored in a memory or other non-transitory computer-readable storage medium or device (e.g., solid state storage devices, disk drives, etc.). The various functions disclosed herein may be embodied in such program instructions, or may be implemented in application-specific circuitry (e.g., ASICs or FPGAs) of the computer system. Where the computer system includes multiple computing devices, these devices may, but need not, be co-located. The results of the disclosed methods and tasks may be persistently stored by transforming physical storage devices, such as solid state memory chips or magnetic disks, into a different state. In some embodiments, the computer system may be a cloud-based computing system whose processing resources are shared by multiple distinct business entities or other users.

Depending on the embodiment, certain acts, events, or functions of any of the processes or algorithms described herein can be performed in a different sequence, can be added, merged, or left out altogether (e.g., not all described operations or events are necessary for the practice of the algorithm). Moreover, in certain embodiments, operations or events can be performed concurrently, e.g., through multi-threaded processing, interrupt processing, or multiple processors or processor cores or on other parallel architectures, rather than sequentially.

The various illustrative logical blocks, modules, routines, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware (e.g., ASICs or FPGA devices), computer software that runs on computer hardware, or combinations of both. Moreover, the various illustrative logical blocks and modules described in connection with the embodiments disclosed herein can be implemented or performed by a machine, such as a processor device, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A processor device can be a microprocessor, but in the alternative, the processor device can be a controller, microcontroller, or state machine, combinations of the same, or the like. A processor device can include electrical circuitry configured to process computer-executable instructions. In another embodiment, a processor device includes an FPGA or other programmable device that performs logic operations without processing computer-executable instructions. A processor device can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Although described herein primarily with respect to digital technology, a processor device may also include primarily analog components. For example, some or all of the rendering techniques described herein may be implemented in analog circuitry or mixed analog and digital circuitry. A computing environment can include any type of computer system, including, but not limited to, a computer system based on a microprocessor, a mainframe computer, a digital signal processor, a portable computing device, a device controller, or a computational engine within an appliance, to name a few.

The elements of a method, process, routine, or algorithm described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module executed by a processor device, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of a non-transitory computer-readable storage medium. An exemplary storage medium can be coupled to the processor device such that the processor device can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor device. The processor device and the storage medium can reside in an ASIC. The ASIC can reside in a user terminal. In the alternative, the processor device and the storage medium can reside as discrete components in a user terminal.

Conditional language used herein, such as, among others, “can,” “could,” “might,” “may,” “e.g.,” and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements or steps. Thus, such conditional language is not generally intended to imply that features, elements or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without other input or prompting, whether these features, elements or steps are included or are to be performed in any particular embodiment. The terms “comprising,” “including,” “having,” and the like are synonymous and are used inclusively, in an open-ended fashion, and do not exclude additional elements, features, acts, operations, and so forth. Also, the term “or” is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term “or” means one, some, or all of the elements in the list.

Disjunctive language such as the phrase “at least one of X, Y, or Z,” unless specifically stated otherwise, is otherwise understood with the context as used in general to present that an item, term, etc., may be either X, Y, or Z, or any combination thereof (e.g., X, Y, or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y, and at least one of Z to each be present.

While the above detailed description has shown, described, and pointed out novel features as applied to various embodiments, it can be understood that various omissions, substitutions, and changes in the form and details of the devices or algorithms illustrated can be made without departing from the spirit of the disclosure. As can be recognized, certain embodiments described herein can be embodied within a form that does not provide all of the features and benefits set forth herein, as some features can be used or practiced separately from others. The scope of certain embodiments disclosed herein is indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.