See what our 2021 looked like. Numbers grow, the goal stays the same – to deliver a stellar client service to you and the best possible online experience to your users. Thank you for trusting in us. 

With CDN77 you now benefit from flat overages and enjoy the flexibility to change your traffic plans on a monthly basis. Read for more details.

High Overage Fees & Rigid Commitments are Passé at CDN77

Continuous improvement of product and service aspects is a standard for most tech enterprises; pricing, however, often remains overlooked. Yet this is exactly what sets market leaders apart – their ability to quickly adapt and respond to client’s changing business needs.

At CDN77, all of our clients now benefit from having overage fees set at the unit price of their CDN traffic plan. What’s more is that they enjoy the freedom to easily upgrade or downgrade their plans on a monthly basis. 

This month we've accomplished our long-term goal – a pricing reform where all of our clients have their overage (additional data that exceeds your subscribed traffic volume) fees equal to the unit price of their chosen plan.

When our clients consume more traffic than they subscribe to, we don’t see that as data excess, we would rather see that as growth that we’re here to support.

Let’s see an example. Imagine you’re subscribed to a 3,000TB Plan at $6,600 per month. This means your unit price is $2.2/TB ($6,600/3,000TB). When you transfer more than 3,000TB of traffic in a given month – let’s say 3,500TB – the additional 500TB will be charged at the same rate ($2.2/TB) as the previous 3,000TB. So, your final payment would be $7,700 ($2.2 * 3,500TB).

Over the course of the past 12 months we applied this pricing model to our Custom and High Volume plans. Preset Monthly Plans adjustment marked the end of the transition process this summer, which effectively means that the overage fees are now capped at the unit price for all of CDN77's plans.

We’re committed to finding the best fitting solution for all of our clients by consulting their individual use-cases, on both technical and pricing levels. If you’d like to learn more about our services, reach out to our Client Solutions team at clientsolutions@cdn77.com.

Internet usage has never been predictable. The 48% increase in global internet traffic during the 2020 pandemic is a powerful demonstration of traffic volatility. 

At CDN77, we reckon with changes in websites’ and apps’ popularity, traffic seasonality as well as sudden peaks in visits. 

While our 70Tbps+ network absorbs any unexpected traffic surges from the capacity point of view, we make sure to reflect traffic unpredictability also in pricing.

In practice it means that our clients have the freedom to flexibly upgrade or downgrade their traffic plan on a monthly basis according to their actual needs. With no rigid commitments in place, you get the optimal pricing solution, whether you’re experiencing rapid growth or going through a lower traffic span.

For example, you might need a 800 TB/month plan for January, then you can downgrade to 550 TB/month in February and upgrade to 3,500 TB/month in March – if that's how your traffic consumption works, it’s no problem for us.

The combination of flexible plan switching and flat rates for overage traffic makes CDN77 a partner to rely on in all stages of your business.

Adjust Your Plan According to Current Traffic Needs

When serving content via CDN, every requested URL must be evaluated against hundreds of millions of values stored in any chosen data center. And it has to happen fast. Learn about how hashing fits into the picture.

When serving content via CDN, every requested URL must be evaluated against hundreds of millions of values. And it has to happen fast. Learn about how hashing fits into the picture.

Top network infrastructure is a must for fast and reliable content delivery. But it doesn't work on its own. Every requested URL must be evaluated against hundreds of millions of values stored in any chosen data center. And it has to happen fast. We're talking milliseconds. That's when hashing comes into play.

In recent years, the word "hashing" has become well known even among non-tech people mostly thanks to the growing crypto market. Generally speaking, we use a hash function (#) to map data of arbitrary length to a range defined by a hash function. Bitcoin, for example, checks whether the final hash is less than the difficulty level, making it valid and eligible to add to the chain. [1]

In terms of content delivery, hashing is crucial for increasing the efficiency of various parts of the delivery process. In the example below, we will quickly discover how calculating hashes speeds it up.

Imagine you are given the task of building a simple CDN. For simplification,  you can ignore all metadata, such as headers, and you are only required to check whether any of the servers have the desired URL in cache or not.

The most naive and obviously wrong approach would be using string matching. You store cached URLs in an array of strings, check for equality, and do that on every server. The complexity of this approach is m x n, where m is the length of string and n is a number of cached URLs on all your servers).

Simple math: This solution quickly becomes infeasible, even with relatively small numbers. The URL to the background image on our homepage https://www.cdn77.com/_next/image?url=%2Fimage%2Fpage%2Fhome%2Fglobe.png&w=3840&q=75 is 84 characters long (m). We need to fetch it from a DC with 100 servers, with each having 10 million files in a cache (n). 84 x 100 x 10 000 000 = 84 000 000 000.

This means that a single 1GHz processor would take 89 seconds(!) just to find the file in cache. Even if you do it concurrently on all 100 servers,  it would take almost a second to serve a single file. With millions of requests every second, it's evident that just throwing more computing power at the problem won't do it. It will waste a lot of computing power only to come up with a lot of "no" answers and maybe one "yes".

Hashing is a way you want to take. Keep in mind that all the examples that I'm about to provide still give you an extremely simplified description of reality, but enough to give you an idea of what happens when a user's request is delivered to one of our PoPs.

We can upgrade the above approach by storing a hash of the URL instead of its string value. Now, when the server is queried for URL, it will first hash it to an integer and use it as a key. We can then easily search for such a key with logarithmic complexity at worst using a suitable data structure (e.g., AVL or any other balanced tree). That's a significant improvement over the first solution. Instead of m x n, we reduced search time to log(n). But still, doing it on all the servers would be too costly.

Every PoP consists of hundreds of servers, and we can't query them all for the same thing. We need to pick the server before asking it whether it has the URL in a cache.

The most straightforward solution is to number your servers and map those numbers to their IP address. When a request reaches the PoP, you will first hash the URL to an integer and then modulo it by the number of servers (k). The result of key mod k will always be the correct server to ask if it has the requested URL in a cache. This is a well-known load balancing technique.

If the number of servers stayed the same, we would be done here. But that is rarely the case. In reality, we often want to scale up and add some servers to the pool or take some down for maintenance. Every time the number of servers changed, every key mod j (new no. of servers) would point to a different server, and the entire cache would effectively be lost. A minor modification will solve that.

Consistent hashing directly addresses the problem of changing the number of servers. Instead of assigning one number to the server, we map them to several (hundreds realistically) unsigned integers, evenly distributed in the unsigned int range (2^32). Conceptually, you can imagine a clock face on which each server appears several times.

An incoming request for a URL is hashed to a single integer. The next biggest number on the clock is the correct server, which should hold the requested file. If the value of the hash is greater than the biggest number assigned to any server, we choose the first one.

Combining this approach with an appropriate hash function guarantees that only a tiny portion of keys end up pointing to a different server when we add or remove one.

Consistent hashing also boosts the performance of a multi-layered setup we have described here (although maybe not so much boosts as makes it possible).

When the request needs to be forwarded to the next layer, we instantly know not only where the next layer is located, but we also know which server exactly should have the requested file in cache. The mechanism is identical to choosing a server inside a single data center.

Trie, or prefix tree, fits the case of a CDN almost perfectly. Lookup complexity is linear with a length of string, the same as calculating the hash. Unfortunately, they won't help with the second function of hashing, which is choosing the correct server. 

That being said, we do use prefix trees and numerous other structures for more complex operations than simple lookups, such as prefix purge.

Milliseconds matter to us, and we are always looking for new ways to improve and speed up one thing or another. Visit our website to learn more about our network and other CDN features.

Even tiny optimizations become noticeable during traffic peaks. Search must be nearly instantaneous, at the rigth location and on the correct server. Sufficient hashing power is helping us do just that.

[1] https://blockgeeks.com/guides/what-is-hashing/#The_mining_process 

For websites or apps with long-tail content, the traditional CDN approach may not be sufficient. That’s when a multilayer cache comes into play. Read how it works and why do we offer it as part of our custom solutions.

Tackling long-tail content: How to get the cache hit ratio above 97%?

Having the majority of content served from the cache comes with clear benefits. It will improve the performance, offload origin servers, and cut the related egress costs. In CDN77, we’ve successfully aimed to keep the average cache hit ratio above 97% for our clients. Yet, in some cases, reaching these figures can be quite challenging.

When every piece of your content is only requested a few times, but the sum of those requests amounts to considerable traffic, the traditional CDN approach may not be sufficient. Such content is frequently referred to as “long-tail”. But is it still possible to benefit from CDN? Well, yes, it is, and the answer lies in a multilayer cache.

In an ideal case, demand for your data follows the normal distribution, and you can easily cache the most wanted content. As users lose interest, it falls down on the curve to the point where caching it would no longer make sense. Simply setting a reasonable threshold works wonders for the cache hit ratio.

For long-tail cases, setting a single threshold becomes meaningless. Most of your content would never make it into the cache, and if it did, it would almost never be served from cache again. It would be soon replaced by content requested after it, pushing the hit ratio very low.

An example could be an educational platform with a wide range of subjects. These sites have enormous traffic, but there is no top content for the majority of users. Instead, people choose whatever they currently need from an extensive archive.

The absence of the most wanted content is frequent but not the only scenario that creates long-tail. Some VOD platforms must also deal with a long-tail, even if they can identify the most played content. The problem emerges from the nature of adaptive bitrate streaming. URLs for various qualities differ, so the content would have to be requested enough times to pass a caching threshold for each quality separately. Take HLS and DASH, each with 4 adaptive profiles, and you end up with 8 different copies of each piece of content. People can, and often do, also request only parts of the video. This fragmentation can negatively affect the performance of your CDN.

The solution to this challenging problem is, in fact, relatively simple. We can set up multiple layers of cache that, eventually, converges to a majority of the content stored on the origin.

If you’re having trouble with the hit ratio for your long-tail content, a multilayer cache is your go-to solution. It’s fully customizable and you can try it out yourself. Our awesome Client Solutions team will be happy to provide more information and offer you a tailored trial. We provide a multilayer cache as a part of our custom solutions along with additional benefits such as dedicated Infrastructure, scalability with the size of origin, and more.

Each layer of the cache works with a different threshold.

The first layer (L0) consists of a multitude of edge servers located in our PoPs. It’s closest to the end-user and stores the most wanted content. Let’s say that you cache your file there when it’s requested at least 10 times.

The second layer (L1) is distributed along some of our bigger data centers, close to the respective PoP and to the user. It also consists of a number of servers and will get requests for content from L0 fairly often. We can imagine a 5 request caching threshold.

And finally, the third layer (L2). Servers on this layer store the actual long-tail content. That means you’ll want to cache anything with at least one request. It’s located closest to the origin and will serve most of the content instead of it. If the file is not in the cache, only then will this layer send the request to the origin, pushing egress costs to a minimum.

There is no “one size fits all” approach. A solution that works in one region doesn’t necessarily have to perform so well in another. For example, you may need L2 in 6 different locations on one continent and only 2 on another. You may even end up not needing one of the layers somewhere. We optimize the topology of all layers to maximize performance in all geolocations.

The hit ratio for such a setup is cumulative. You can expect a pretty low ratio on edge servers – that is the reason we go through all this trouble, after all. Each layer will, however, perform progressively better than the previous one. L0+L1 together will take care of the most wanted content in the area, while L2 holds mostly the long-tail.

You may assume that to keep the hit ratio high, L2 should hold almost all of the data from origin. That’s not actually necessary. When a URL is requested enough times to warrant caching the file closer to users, it will result in a fewer number of requests (zero in fact) at subsequent layers. After some time, it will be replaced by more recent, less requested content. This allows you to distribute files evenly across the layers and use available space much more efficiently without duplicates in a cache.

In the event of a failure at any layer, our optimized failover mechanism will forward traffic to a backup, which is chosen with regards to latency and cache hit probability.

CDN for long-tail content? Fight the cache miss with multilayer caching!