4 ms·
It depends how much time is spent doing computation and how much time is spent doing lookups from disk. If the latter is clearly dominating, then a switch to Go
by jlouis 13y ago
It depends how much time is spent doing computation and how much time is spent doing lookups from disk. If the latter is clearly dominating, then a switch to Go will not help much.
- billybob255 13y agoI read a comment from one of the sysadmins (alienth?) saying their main bottlenecks were I/O.
- espeed 13y agoWith all of Reddit's past problems with AWS and EBS (https://news.ycombinator.com/item?id=2339214 https://news.ycombinator.com/item?id=2339214, https://news.ycombinator.com/item?id=2469838 https://news.ycombinator.com/item?id=2469838, ), I figured they would haved jumped to Google Compute Engine by now, which has much better IO all around (http://gigaom.com/2013/03/15/by-the-numbers-how-google-compute-engine-stacks-up-to-amazon-ec2/ http://gigaom.com/2013/03/15/by-the-numbers-how-google-compu...).
- diminish 13y agothanks for the insight. i did not have much to do with Go. But hear a lot of positive benchmarks here on HN. Reddit is kind of like an example social web app, and I read a lot on its architectural changes and scaling efforts. So for social Web 2.0 apps, which are getting older now, I m curious how much Go would make a difference. Mainly for Google applications, apparently Go brings a lot of speed and performance on the same server.
- jacques_chester 13y agoIt doesn't really matter what the genre of an application is. What matters is the runtime fundamentals. How much time is spent computing vs waiting for I/O? Whichever one is slower is the current bottleneck and is what you should fret about. Go becomes something to consider if the bottleneck is computation time. It's tangential otherwise.