3 ms·

I disagree. Most content on government sites is static content, you could fairly easily deliver much of that to a large population with relatively little hardwa

I disagree. Most content on government sites is static content, you could fairly easily deliver much of that to a large population with relatively little hardware, assuming the software is developed such that static delivery is possible. There are "processes" that people need to complete, but these are typically life-changing processes, things you do once in your life, or maybe once a year at most. Even if those are clustered in time as you say, and most aren't, it doesn't take a lot of hardware to run most of those processes, especially if again the software is designed well and to pull things off the critical path that don't need to be. The healthcare.gov rollout is often pointed to as an example of these things going wrong, the site crashed, and it would be easy to say it needed more hardware, but actually the core issue was that it was "enterprise software" – it was software built by people used to building software for small numbers of expert users in a company who might go through training, who might be using on-prem servers, who might have a lot of complex business requirements. The big improvement came when a bunch of producty-UXy sorts of people came along and scrapped most of the system, made a simple piece of user-facing software that did the minimum necessary, and built it with modern (at the time) web technologies, not from throwing hardware at it.

bruce511 2y ago
Yep HealthCare.gov , but its by far not the only site to struggle. And hardware goes beyond cpu and includes things like hardware for the database, resilient fall-over, network bandwidth (ok, less of an issue these days) and so on. Sure, it takes more than -just- hardware, and yes sites can be more-or-less resource hungry. But ultimately "the server is offline" is not a good thing. Lots of things cluster when you don't expect it. Like sites to take bookings for national parks (as an example).
8organicbits 2y ago
> things you do once in your life, or maybe once a year at most I don't think that's the case. Analytics [1] for the top web pages in the US Federal government are: * GSA advantage - a search tool * Visa instructions - static? * USPS tracking - a search tool * ESTA application - a form * NWS Radar - weather radar * Sex offender registry - search tool Checking the weather or shipping a package are much more common than yearly activities. Of course anything that is static will be behind some sort of cache, but the DevOps team is focused on scaling the dynamic parts. [1] https://analytics.usa.gov/ https://analytics.usa.gov/
- ndriscoll 2y ago
  USPS tracking should be using an indexed id (you don't want to allow partial matches/searches here), so I'd expect even very modest hardware to handle 10s of thousands of requests per second. Likewise with things like CRUD forms. Right now your link shows only ~5700 requests in the last 30 minutes for GSA advantage, or ~3/s. Sex offender registry has ~3500/30m or 2/s. Even USPS tracking is only at ~12k/30m or ~7/s. It's still only 9am on the west coast so maybe they need to handle 100000x traffic for peaks, but I doubt it.

bruce511 2y ago

Yep HealthCare.gov , but its by far not the only site to struggle. And hardware goes beyond cpu and includes things like hardware for the database, resilient fall-over, network bandwidth (ok, less of an issue these days) and so on. Sure, it takes more than -just- hardware, and yes sites can be more-or-less resource hungry. But ultimately "the server is offline" is not a good thing. Lots of things cluster when you don't expect it. Like sites to take bookings for national parks (as an example).

8organicbits 2y ago

> things you do once in your life, or maybe once a year at most I don't think that's the case. Analytics [1] for the top web pages in the US Federal government are: * GSA advantage - a search tool * Visa instructions - static? * USPS tracking - a search tool * ESTA application - a form * NWS Radar - weather radar * Sex offender registry - search tool Checking the weather or shipping a package are much more common than yearly activities. Of course anything that is static will be behind some sort of cache, but the DevOps team is focused on scaling the dynamic parts. [1] https://analytics.usa.gov/ https://analytics.usa.gov/

ndriscoll 2y ago
USPS tracking should be using an indexed id (you don't want to allow partial matches/searches here), so I'd expect even very modest hardware to handle 10s of thousands of requests per second. Likewise with things like CRUD forms. Right now your link shows only ~5700 requests in the last 30 minutes for GSA advantage, or ~3/s. Sex offender registry has ~3500/30m or 2/s. Even USPS tracking is only at ~12k/30m or ~7/s. It's still only 9am on the west coast so maybe they need to handle 100000x traffic for peaks, but I doubt it.