For this reason a generic topology exists. Not every customer would want to personalize their topology. Enterprise customers usually have dedicated infrastructure teams that work with our solutions engineers to manually optimize and maintain their tiered cache topology. The best topology is a configuration based on information that is privately held by the customer and other information held only by Cloudflare.įor instance, knowing the desired balance of latency versus cache hit ratio is information only the customer has, but how to best make use of the Internet is something we would know. In Tiered Cache, the topology describes which data center should serve as a proxy for others.įor customers, devising an optimal topology is a challenge requiring optimization and continuous maintenance. Fewer requests to the origin are made overall. If the proxied data centers make requests for the same asset, the asset will already be cached in the proxying data center and can be retrieved from there rather than from the origin. With Tiered Cache, certain data centers are reverse proxies to the origin for other data centers. Tiered Cache improves cache hit ratios by allowing some data centers to serve as caches for others, before the latter has to make a request to the origin. This is precisely what Tiered Cache does. To avoid querying each data center, a copy of the asset has to be stored in a known location after the first cache miss so it is available to other data centers. However, the asset has to be copied from somewhere and it isn’t possible to know where in the network it might be without querying each data center. Instead, a good heuristic is to move the asset into the nearest cache after the first cache miss. The minimum possible cache hit latency is achieved if the asset is moved into the nearest cache before the request for it is made, but this kind of prediction is generally not possible. However, sending every request to every data center is not practical. Theoretically, a request for the asset would have to be sent to every data center in order to reduce the cache misses to the minimum possible. This is because the data centers are completely oblivious of each other. A request to the origin for one asset could be made as many times as there are data centers.Ī cache miss in any data center will result in a request being sent to the origin server even if the asset is cached in some other data center. In this scheme, a miss in any data center causes a request to the origin for an asset. The standard method for caching assets is to let each data center be a reverse proxy for the origin server. Today we’re introducing Smart Topology, which maximizes cache hit ratios by building on Argo’s internal infrastructure to identify the single best data center for making requests to the origin. By default, we use a generic topology for every customer that strikes a balance between cache hit ratios and latency that is suitable for most users. The number and location of the data centers used by Tiered Cache is controlled by a piece of configuration called the topology. With Tiered Cache active, a request in South Africa won’t go directly to an origin in North America, but, instead, look in a large, nearby data center to see if the data requested is cached there first. Tiered Cache is an Argo feature that reduces the number of data centers responsible for requesting assets from the origin. Argo observes network conditions and finds the optimal route across the Internet for origin server requests, avoiding congestion along the way. A few years ago, we released Argo to help make the Internet faster and more efficient.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |