3 ms·

Andrew White at the GDS[0] wrote about "Scaling the Petitions service following the EU Referendum"[1] back in August 2016. I wonder if we'll have another write

Andrew White at the GDS[0] wrote about "Scaling the Petitions service following the EU Referendum"[1] back in August 2016. I wonder if we'll have another write up after this petition? [0] https://www.gov.uk/government/organisations/government-digital-service https://www.gov.uk/government/organisations/government-digit... [1] https://technology.blog.gov.uk/2016/08/16/scaling-the-petitions-service-following-the-eu-referendum/ https://technology.blog.gov.uk/2016/08/16/scaling-the-petiti...

deleted 8y ago
[deleted]
pbhjpbhj 8y ago
>The following morning, White conceded defeat and explained the technical error that had led to the failure. “Well done everyone – the site crashed because calculating the trending count became too much of a load on the database.” // The reasoning seems spurious, is not that difficult for a db to keep a row count .. and of it were then you could do that out of bounds. 1k updates per minute it's surely not that much traffic for a national site; I wonder what max-load they designed for? If 1M users hit it in a work day then that's 2k users a minute, which seems to be quite a reasonable normal level to design for (there are many petitions, you want to cope with a few being popular on any day; maybe 10k user max load??). The db is just going to be something like petition index+user index. Is the reason given just bluster?
- pbhjpbhj 8y ago
  More info at https://technology.blog.gov.uk/2016/08/16/scaling-the-petitions-service-following-the-eu-referendum/ https://technology.blog.gov.uk/2016/08/16/scaling-the-petiti.... I'm not a db person, but are they sharding. Surely as they're only writing simple tuples with a petition they can easily write to multiple separate dbs (shards I guess) and amalgamate the results at leisure? That link says they need to update the web content perpetually, but it seems it's only the number of signatories they need to keep live, isn't it. So once it breeches 100k then they can estimate the signatory rate (including acceleration) and update the row count when they think 200k will be breeched - at 1k/min updating the row count each hour is fine, presumably. Surely that's not a massive processing job? I'd love some input here, because naively it seems like they're not handling that much data? A million rows of 1kB is still only 1GB, and they're only gathering a few simple fields in each tuple??

deleted 8y ago

[deleted]

pbhjpbhj 8y ago

>The following morning, White conceded defeat and explained the technical error that had led to the failure. “Well done everyone – the site crashed because calculating the trending count became too much of a load on the database.” // The reasoning seems spurious, is not that difficult for a db to keep a row count .. and of it were then you could do that out of bounds. 1k updates per minute it's surely not that much traffic for a national site; I wonder what max-load they designed for? If 1M users hit it in a work day then that's 2k users a minute, which seems to be quite a reasonable normal level to design for (there are many petitions, you want to cope with a few being popular on any day; maybe 10k user max load??). The db is just going to be something like petition index+user index. Is the reason given just bluster?

pbhjpbhj 8y ago
More info at https://technology.blog.gov.uk/2016/08/16/scaling-the-petitions-service-following-the-eu-referendum/ https://technology.blog.gov.uk/2016/08/16/scaling-the-petiti.... I'm not a db person, but are they sharding. Surely as they're only writing simple tuples with a petition they can easily write to multiple separate dbs (shards I guess) and amalgamate the results at leisure? That link says they need to update the web content perpetually, but it seems it's only the number of signatories they need to keep live, isn't it. So once it breeches 100k then they can estimate the signatory rate (including acceleration) and update the row count when they think 200k will be breeched - at 1k/min updating the row count each hour is fine, presumably. Surely that's not a massive processing job? I'd love some input here, because naively it seems like they're not handling that much data? A million rows of 1kB is still only 1GB, and they're only gathering a few simple fields in each tuple??