3 ms·

This also strikes me as another "You're Not Google" example. With modern computers, where even the smallest instance currently available on AWS would have been

by jerf 4y ago

This also strikes me as another "You're Not Google" example. With modern computers, where even the smallest instance currently available on AWS would have been a beefy system when this advice was first diffused into the community, CDNs are probably solving a problem you don't have in 2022. If you have 10MB of static files to serve, and they're decently cached, you're looking at the ability to serve on the order of 50-100 new users per second with very realistic setups nowadays that would still be generally considered "entry level" in the modern environment, while in the meantime consuming almost no resources on the server because serving static files is really easy. And that's just straight off the "main server". If you've run the numbers, and that's a problem, hey, great, more power to you! There's web sites where that's a problem. But, you know, remember that 100 new users per sec is a scale of nearly 10,000,000 per day. Is that really your scale? There's an awful lot of sites, even busy, productive, and profitable sites, that are looking more at the "1 new user loading a fresh copy of these things per second", if not one per minute. I remember working with "servers" in the low hundreds of megahertz, on software stacks a lot less optimized than today. Shifting around your static serving could do something then. Today? Choking even a single CPU server's capability to serve static content takes some doing. By the time that's your core problem, you'll know. (There's still a lot of "best practices" banging around the community from the "low hundreds of megahertz" period of time. At the risk of goring some sacred oxes, I also consider the obsession with total statelessness to date from this era. While one must still be careful with it, judicious application of state in the modern era can be very helpful. It's less panic-inducingly terrifying when I can afford the equivalent of entire servers dedicated to each individual user, where "server" is defined as "a server class machine from the time this advice first percolated out". The software engineering considerations around state are relevant and must be considered, but the solution of "zero! none! never! not any!" is no longer the only viable or best choice.)

sleepydog 4y ago
While I agree we should not assume a cdn is necessary, as far as user traffic is concerned, not all seconds are created equal. Those pesky users have a habit of making requests at the same time, like they're in cahoots with one another. Whether it's because they're all in the same time zone and they just got home from work, or the clock struck midnight and your fire sale has begun, you don't provision for average qps, you provision for peak qps. This does not negate your argument, in fact for many use cases doing your own caching could be a better way to meet increased demand (certainly a cheaper way). CDN-related issues can be incredibly difficult to troubleshoot, too, especially without a support contract.
- jerf 4y ago
  By all means, if You Are Indeed (Some Reasonable Fraction Of) Google, then by all means, take that seriously. But I can tell you from personal experience I've been asked to produce a "CDN plan" for content access on the order of once a minute during peak hours, and which had no reasonable business case for distributing enough to matter. I am personally responsible for one system that does need CDN-like capability, because it does serve static files at a rate and a required reliability that a single server can't meet. (We don't use a "real" CDN because for our use case it would be absurdly expensive, but we're keeping an eye on the offerings out there.) So I do know they can exist. But even that system is, in 2022, on the lower end of what you would need such a thing for, and it is serving multi-gigabyte images out on a fairly routine basis to many tens of thousands of consumers (which are automated systems, not humans). That's what it takes to be on the "low end" of blowing out a normal static file server. 15 years ago these systems were a royal pain to maintain, at a much lower level of usage, and non-trivial effort was spent optimizing what they serve. Today, they mostly just hum away doing their job.
marcosdumay 4y ago
> I also consider the obsession with total statelessness to date from this era People were less obsessed with statelessness back then. There was some push for statelessness (peaking at the time of the 10K problem), but it was much less than now. I believe the current wave is entirely caused by the publicity of the "we rent IaS, but not as commodity computers" cloud, and doesn't have any technical origin.
toast0 4y ago
> If you have 10MB of static files to serve, and they're decently cached, you're looking at the ability to serve on the order of 50-100 new users per second with very realistic setups nowadays that would still be generally considered "entry level" in the modern environment, while in the meantime consuming almost no resources on the server because serving static files is really easy. And that's just straight off the "main server". If your web page needs 10MB of static files to load, you're going to need a lot of round trips to get that to your users. Your server and clients may be on 10G ethernet, but that 10MB download is still going to be limited by 'slow start' congestion control unless the round trip time is low. That's why people want to use CDNs more than reducing resource use of serving static files (which is pretty low as you mention).
bo1024 4y ago
But as a user, I don’t want to waste time (and resources) re-fetching the same library from different sites all the time. I might not be somewhere with a good internet connection or I might pay for data, etc.
- jerf 4y ago
  You increasingly don't get a choice. Due to the ability to fingerprint people by measuring how long it takes to access resources, browsers are moving in the direction of completely sharding the cache by site anyhow to secure people away from that. If they're not already all there, they are getting pretty close. The argument in favor of a CDN in terms of "hoping the user already has jQuery or something in their cache" is nearly dead now. I seem to recall some people measuring the effect even before it was dead, and the hit rate was never all that great anyhow. There were so many versions of jQuery, so many other libraries, and so many CDNs, it still didn't hit as often as you might think.
jjav 4y ago
> With modern computers, where even the smallest instance currently available on AWS would have been a beefy system when this advice was first diffused into the community Cloud VM instances are for the most part very underpowered (and for the performance, overpriced). You'd have to go far back a lot of years to get to an era where a "beefy system" of the time was as weak as the smallest AWS instance (t2.nano?)

by jerf 4y ago

sleepydog 4y ago

While I agree we should not assume a cdn is necessary, as far as user traffic is concerned, not all seconds are created equal. Those pesky users have a habit of making requests at the same time, like they're in cahoots with one another. Whether it's because they're all in the same time zone and they just got home from work, or the clock struck midnight and your fire sale has begun, you don't provision for average qps, you provision for peak qps. This does not negate your argument, in fact for many use cases doing your own caching could be a better way to meet increased demand (certainly a cheaper way). CDN-related issues can be incredibly difficult to troubleshoot, too, especially without a support contract.

jerf 4y ago
By all means, if You Are Indeed (Some Reasonable Fraction Of) Google, then by all means, take that seriously. But I can tell you from personal experience I've been asked to produce a "CDN plan" for content access on the order of once a minute during peak hours, and which had no reasonable business case for distributing enough to matter. I am personally responsible for one system that does need CDN-like capability, because it does serve static files at a rate and a required reliability that a single server can't meet. (We don't use a "real" CDN because for our use case it would be absurdly expensive, but we're keeping an eye on the offerings out there.) So I do know they can exist. But even that system is, in 2022, on the lower end of what you would need such a thing for, and it is serving multi-gigabyte images out on a fairly routine basis to many tens of thousands of consumers (which are automated systems, not humans). That's what it takes to be on the "low end" of blowing out a normal static file server. 15 years ago these systems were a royal pain to maintain, at a much lower level of usage, and non-trivial effort was spent optimizing what they serve. Today, they mostly just hum away doing their job.

marcosdumay 4y ago

> I also consider the obsession with total statelessness to date from this era People were less obsessed with statelessness back then. There was some push for statelessness (peaking at the time of the 10K problem), but it was much less than now. I believe the current wave is entirely caused by the publicity of the "we rent IaS, but not as commodity computers" cloud, and doesn't have any technical origin.

toast0 4y ago

> If you have 10MB of static files to serve, and they're decently cached, you're looking at the ability to serve on the order of 50-100 new users per second with very realistic setups nowadays that would still be generally considered "entry level" in the modern environment, while in the meantime consuming almost no resources on the server because serving static files is really easy. And that's just straight off the "main server". If your web page needs 10MB of static files to load, you're going to need a lot of round trips to get that to your users. Your server and clients may be on 10G ethernet, but that 10MB download is still going to be limited by 'slow start' congestion control unless the round trip time is low. That's why people want to use CDNs more than reducing resource use of serving static files (which is pretty low as you mention).

bo1024 4y ago

But as a user, I don’t want to waste time (and resources) re-fetching the same library from different sites all the time. I might not be somewhere with a good internet connection or I might pay for data, etc.

jerf 4y ago
You increasingly don't get a choice. Due to the ability to fingerprint people by measuring how long it takes to access resources, browsers are moving in the direction of completely sharding the cache by site anyhow to secure people away from that. If they're not already all there, they are getting pretty close. The argument in favor of a CDN in terms of "hoping the user already has jQuery or something in their cache" is nearly dead now. I seem to recall some people measuring the effect even before it was dead, and the hit rate was never all that great anyhow. There were so many versions of jQuery, so many other libraries, and so many CDNs, it still didn't hit as often as you might think.

jjav 4y ago

> With modern computers, where even the smallest instance currently available on AWS would have been a beefy system when this advice was first diffused into the community Cloud VM instances are for the most part very underpowered (and for the performance, overpriced). You'd have to go far back a lot of years to get to an era where a "beefy system" of the time was as weak as the smallest AWS instance (t2.nano?)