Patent Publication Number: US-11025747-B1

Title: Content request pattern-based routing system

Description:
BACKGROUND 
     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&#39;s content from the network storage provider&#39;s or CDN service provider&#39;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. 
    
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
       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. 
     
    
    
     DETAILED DESCRIPTION 
     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&#39;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. 
     Example Block Diagrams for Pattern-Based Request Routing 
       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. 
     Example Block Diagram for Evicted Cache Content 
       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 . 
     Example Block Diagram for Traffic Level-Based Content Serving 
       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 . 
     Terminology 
     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.