5 ms·
> for each request, Octo typically fetches somewhere between 10–100 keys from S3 I'm really curious as to why this is neccessary - what are the 10-100 keys you
by planetjones 11y ago
> for each request, Octo typically fetches somewhere between 10–100 keys from S3
I'm really curious as to why this is neccessary - what are the 10-100 keys you are fetching per request ? Just reading the high level article it sounds like there is some issue with what this service is doing, irrespective of the language it's doing it in.
- meonkeys 11y agoAnother idea: stress-test a Node.js process then hard-limit the number of requests each Node.js process handles based on that stress test. Add more Node.js processes (one per core on the same or other servers) until there is sufficient capacity to handle all requests. This assumes the Node.js code is already distributable across cores and servers, which seems to be the case based on the article. Might have been a day-long workaround rather than a weeks-long rewrite.
- zaphar 11y agoPart of the goal was fixing this without having to just throw hardware at it. Every Node process has a non-trivial amount of overhead that requires additional hardware resources. Overhead that the Go app doesn't have. They could have thrown more machines at this but that costs money. The better solution technology wise was Go. It was better suited to their workload.
- jongleberry 11y agoMy same thought as well. S3 has a rate limit, which is where a lot of these timeouts or errors are probably happening. Seems like they should be using a database instead.
- zimpenfish 11y agoIf it's anything like the websites I've worked, 10s (sometimes even 100s) of database requests to render a page isn't all that strange.
- CydeWeys 11y agoWell, it's Digg, so maybe each key is a comment? That's entirely reasonable. I can think of any number of sample web applications that would require loading dozens of objects from a DB per page load.