3 ms·

Interesting comment. Scaling "out" is costly in complexity and only needed... well... If it is needed! 700k transactions per second on a single machine from 20

by gbin 4y ago

Interesting comment. Scaling "out" is costly in complexity and only needed... well... If it is needed! 700k transactions per second on a single machine from 2013 is probably millions per second on a modern machine. We need to be careful and always ground the scale to reality, for example: the number of flight reservations per year worldwide is ~3B. Let's say you have 10 attempts / search per résa: 30B, then 3 transaction per, 90B. This is still less than 300 transactions per second in average! I believe the lost art of squeezing out the performance of one machine is very valuable in today's world because a single machine can definitely achieve "most applications" at the human scale with no atomic clock to sync db transactions across the planet with thousands of nodes.

amelius 4y ago
Yeah, but flights are relatively expensive and aren't scheduled as often as e.g. social media messages are sent. Also, you always have to be prepared for bursts of requests. And of course some new requirements can always be thrown in by management which may invalidate any assumptions you made about speed.
- jandrewrogers 4y ago
  Any data source where events are created by intentional human action, including global social media platforms, have relatively trivial event rates even during bursts. It isn't the event rate that gets you, it is the rest of the workload processing and serving content. Just landing and storing the events can be easily handled by a single modern server with capacity to spare. Machine sourced data, by comparison, has event rates that are orders of magnitude higher.
threeseed 4y ago
Scaling out isn't just about performance. It's also about high availability. Which is something everyone needs to consider when using cloud infrastructure. AWS provides 99.5% EC2 uptime guarentees which is ~2 days a year of outages. That is not simply acceptable for most use cases and is why a single server just won't cut it.
- KronisLV 4y ago
  > AWS provides 99.5% EC2 uptime guarentees which is ~2 days a year of outages. > That is not simply acceptable for most use cases and is why a single server just won't cut it. I agree with your point in principle, but I wonder why this should be applicable to most use cases. Our national tax reporting system failed on the first day when you could submit taxes that year and has done so across multiple years - and yet everyone just submits their reports a bit later and it's fine in the end. Our e-health system users would be glad to have only a few days of outages per year, instead it doesn't work most of the time, due to the project being an abject failure that padded the wallets of many of who were involved in "making" it. Our national COVID vaccine signup system failed on the first day, even though they attempted to implement queuing of requests, most people were only able to sign up days later. You hear on HN about Cloudflare outages, Google outages, GitHub outages and so on occasionally. I understand why you might want resilience for something like pacemakers or airplane systems, but surely most CRUD apps or cloud based services out there aren't actually that important, we just make it seem like they are, in fear of users going to competition during the outage or something.
  - WJW 4y ago
    The tax and eHealth systems have the advantage of being monopolies though, it's not like you can go to another tax service with better ICT (except by emigrating of course), and it's literally illegal to not use the system at all (because you have to pay your taxes), so you can't even choose not to use it. Most companies do have competitors, so "we are more reliable" becomes a selling point for them. Definitely agree that some companies take their uptime demands beyond the point of diminishing returns though. I once worked at a company which would absolutely not allow 10 minutes of scheduled downtime in the middle of the night but didn't mind at all if I took several months to build a workaround.
  - threeseed 4y ago
    Because engineers usually work for someone. And that someone rarely accepts 2 days a year worth of outages given its impact on revenue.
deleted 4y ago
[deleted]

by gbin 4y ago

amelius 4y ago

Yeah, but flights are relatively expensive and aren't scheduled as often as e.g. social media messages are sent. Also, you always have to be prepared for bursts of requests. And of course some new requirements can always be thrown in by management which may invalidate any assumptions you made about speed.

jandrewrogers 4y ago
Any data source where events are created by intentional human action, including global social media platforms, have relatively trivial event rates even during bursts. It isn't the event rate that gets you, it is the rest of the workload processing and serving content. Just landing and storing the events can be easily handled by a single modern server with capacity to spare. Machine sourced data, by comparison, has event rates that are orders of magnitude higher.

threeseed 4y ago

Scaling out isn't just about performance. It's also about high availability. Which is something everyone needs to consider when using cloud infrastructure. AWS provides 99.5% EC2 uptime guarentees which is ~2 days a year of outages. That is not simply acceptable for most use cases and is why a single server just won't cut it.

KronisLV 4y ago
> AWS provides 99.5% EC2 uptime guarentees which is ~2 days a year of outages. > That is not simply acceptable for most use cases and is why a single server just won't cut it. I agree with your point in principle, but I wonder why this should be applicable to most use cases. Our national tax reporting system failed on the first day when you could submit taxes that year and has done so across multiple years - and yet everyone just submits their reports a bit later and it's fine in the end. Our e-health system users would be glad to have only a few days of outages per year, instead it doesn't work most of the time, due to the project being an abject failure that padded the wallets of many of who were involved in "making" it. Our national COVID vaccine signup system failed on the first day, even though they attempted to implement queuing of requests, most people were only able to sign up days later. You hear on HN about Cloudflare outages, Google outages, GitHub outages and so on occasionally. I understand why you might want resilience for something like pacemakers or airplane systems, but surely most CRUD apps or cloud based services out there aren't actually that important, we just make it seem like they are, in fear of users going to competition during the outage or something.
- WJW 4y ago
  The tax and eHealth systems have the advantage of being monopolies though, it's not like you can go to another tax service with better ICT (except by emigrating of course), and it's literally illegal to not use the system at all (because you have to pay your taxes), so you can't even choose not to use it. Most companies do have competitors, so "we are more reliable" becomes a selling point for them. Definitely agree that some companies take their uptime demands beyond the point of diminishing returns though. I once worked at a company which would absolutely not allow 10 minutes of scheduled downtime in the middle of the night but didn't mind at all if I took several months to build a workaround.
- threeseed 4y ago
  Because engineers usually work for someone. And that someone rarely accepts 2 days a year worth of outages given its impact on revenue.

deleted 4y ago

[deleted]