4 ms·

It's not just limiting to three hours a week, but to three particular hours a week. Feels even more Draconian to me.

by perlgeek 5y ago

toxik 5y ago
Imagine the thundering herd problems you experience when all of your users have the same three hour time slots.
- user123456780 5y ago
  I'd like this to be honest (from an infrastructure point of view). If the time is known for an influx of traffic I can prepare for that. I currently look after a system which gets random spikes of traffic thats critical to serve. Which means I more or less need to run a huge amount of redundant servers 24 hours a day incase there is a spike at 2am. We have horizontal scaling but our traffic has little lead time.
- ctvo 5y ago
  The thundering herd problem in distributed systems is an often unexpected failure mode. This is great, and easy to plan for. You'd save buckets of money because most capacity is used for spikes, and you now have a good idea of when spikes occur. Every Monday, an hour after school, scale up 5x, because the timer has reset for students. Scale down from Wednesday to Friday. Scale up 2x over the weekends. Or whatever your data tells you.
- superfrank 5y ago
  I worked at an ed-tech company for a few years. 80%+ of our traffic came on line in a 2-ish hour every morning. Additionally, because most schools have similar summer break schedules, we'd have this crazy ramp up in August and September where out daily active users would 10x in a little over two weeks. It was actually a pretty unique challenge that had some weird trade-offs. For example, when do you release new code? You've got this nice window at the end of each day when traffic is super low, so any issues with the release will affect a minimal amount of users, but on the other hand, if you release at the end of the day, you don't really know if your code works at scale until the next morning. Similarly, what do you do during the summer period? You've got a couple quiet months in where almost no one is online where you can kind of swing for the fences in terms of changes, but at the same time, you won't really know whether it handle the full load of the customer base until September. Sure there's things like load testing (which we did), but theres no way to truly predict how your customers will use your product. We had a really solid engineering team and ended up coming up with processes to handle a lot of these problems, but still, it was something that I hadn't dealt with before and I found pretty interesting.

It's not just limiting to three hours a week, but to three particular hours a week. Feels even more Draconian to me.

toxik 5y ago

Imagine the thundering herd problems you experience when all of your users have the same three hour time slots.

user123456780 5y ago
I'd like this to be honest (from an infrastructure point of view). If the time is known for an influx of traffic I can prepare for that. I currently look after a system which gets random spikes of traffic thats critical to serve. Which means I more or less need to run a huge amount of redundant servers 24 hours a day incase there is a spike at 2am. We have horizontal scaling but our traffic has little lead time.
ctvo 5y ago
The thundering herd problem in distributed systems is an often unexpected failure mode. This is great, and easy to plan for. You'd save buckets of money because most capacity is used for spikes, and you now have a good idea of when spikes occur. Every Monday, an hour after school, scale up 5x, because the timer has reset for students. Scale down from Wednesday to Friday. Scale up 2x over the weekends. Or whatever your data tells you.
superfrank 5y ago
I worked at an ed-tech company for a few years. 80%+ of our traffic came on line in a 2-ish hour every morning. Additionally, because most schools have similar summer break schedules, we'd have this crazy ramp up in August and September where out daily active users would 10x in a little over two weeks. It was actually a pretty unique challenge that had some weird trade-offs. For example, when do you release new code? You've got this nice window at the end of each day when traffic is super low, so any issues with the release will affect a minimal amount of users, but on the other hand, if you release at the end of the day, you don't really know if your code works at scale until the next morning. Similarly, what do you do during the summer period? You've got a couple quiet months in where almost no one is online where you can kind of swing for the fences in terms of changes, but at the same time, you won't really know whether it handle the full load of the customer base until September. Sure there's things like load testing (which we did), but theres no way to truly predict how your customers will use your product. We had a really solid engineering team and ended up coming up with processes to handle a lot of these problems, but still, it was something that I hadn't dealt with before and I found pretty interesting.