3 ms·

around a couple of years ago it always bugged me that CDNs took 15mins to several hours to recognise changes, much like DNS. this made them useless for real-tim

around a couple of years ago it always bugged me that CDNs took 15mins to several hours to recognise changes, much like DNS. this made them useless for real-time websites I wonder if things have changed since then

cortesoft 4y ago
It is changing. I work for a CDN on a team focused on speeding up config propagation. The modern expectation is global distribution of new configs in seconds.
animesh371g 4y ago
It depends on the TTL set on the cached content in CDN. If the TTL is for several hours, CDN won't show the recent content. Given that the TTL is set appropriately for the content, CDN will behave correctly.
capableweb 4y ago
Much like DNS, it depends on the TTL. But yeah, if you're trying to do real-time stuff, it's best not to cache that with out-of-the-box stock CDN products, but rather have your own caching. Then for the rest of the endpoints/assets, you can use a default CDN. Something some people seem to miss though, is to leverage ETag header properly, so the client and CDN can serve fresh content automatically when it exists, or serve the cached content otherwise. It's not that tricky, but somehow many seems to not even know about it.
rfmoz 4y ago
And the time that you spent waiting to see the logs. They aggreagate them via attached files in mails sended from the pops.
manigandham 4y ago
The problem comes down to how quickly configuration data can be pushed to the edge and modern CDNs like Cloudflare and Fastly respond to changes within seconds, or even milliseconds.
cryptonym 4y ago
Most of the time you change URLs rather than content but it may not apply to real-time scenarios. Some CDN provides distributed key value stores where you can push data in seconds, you can also deploy your own code in minutes (for real time changes you would push data, not code). Some providers expose cache purge APIs so you can clear cached data in seconds. They also allow serving cached content while asynchronously revalidating with the Origin so following users get a fresh version. With proper configuration/architecture they are a great way to scale your real-time website.
nosequel 4y ago
One of the reasons Fastly got used by online newspapers was their fast purge. No newspaper wanted to use CDNs for breaking news if purging took 20 minutes to complete. It was one of the advantages Fastly had that allowed them to get customers from other CDNs. According to https://developer.fastly.com/learning/concepts/purging/ https://developer.fastly.com/learning/concepts/purging/ they do single-object purges in 150ms globally.
- thakoppno 4y ago
  > It was one of the advantages Fastly had that allowed them to get customers from other CDNs. That’s a neat fact and perhaps an advantage usually reserved for new entrants into an entrenched market. Presumably Fastly benefited, at least in some part, from technological innovation that existing companies could not apply as easily.

cortesoft 4y ago

It is changing. I work for a CDN on a team focused on speeding up config propagation. The modern expectation is global distribution of new configs in seconds.

animesh371g 4y ago

It depends on the TTL set on the cached content in CDN. If the TTL is for several hours, CDN won't show the recent content. Given that the TTL is set appropriately for the content, CDN will behave correctly.

capableweb 4y ago

Much like DNS, it depends on the TTL. But yeah, if you're trying to do real-time stuff, it's best not to cache that with out-of-the-box stock CDN products, but rather have your own caching. Then for the rest of the endpoints/assets, you can use a default CDN. Something some people seem to miss though, is to leverage ETag header properly, so the client and CDN can serve fresh content automatically when it exists, or serve the cached content otherwise. It's not that tricky, but somehow many seems to not even know about it.

rfmoz 4y ago

And the time that you spent waiting to see the logs. They aggreagate them via attached files in mails sended from the pops.

manigandham 4y ago

The problem comes down to how quickly configuration data can be pushed to the edge and modern CDNs like Cloudflare and Fastly respond to changes within seconds, or even milliseconds.

cryptonym 4y ago

Most of the time you change URLs rather than content but it may not apply to real-time scenarios. Some CDN provides distributed key value stores where you can push data in seconds, you can also deploy your own code in minutes (for real time changes you would push data, not code). Some providers expose cache purge APIs so you can clear cached data in seconds. They also allow serving cached content while asynchronously revalidating with the Origin so following users get a fresh version. With proper configuration/architecture they are a great way to scale your real-time website.

nosequel 4y ago

One of the reasons Fastly got used by online newspapers was their fast purge. No newspaper wanted to use CDNs for breaking news if purging took 20 minutes to complete. It was one of the advantages Fastly had that allowed them to get customers from other CDNs. According to https://developer.fastly.com/learning/concepts/purging/ https://developer.fastly.com/learning/concepts/purging/ they do single-object purges in 150ms globally.

thakoppno 4y ago
> It was one of the advantages Fastly had that allowed them to get customers from other CDNs. That’s a neat fact and perhaps an advantage usually reserved for new entrants into an entrenched market. Presumably Fastly benefited, at least in some part, from technological innovation that existing companies could not apply as easily.