4 ms·
At the point where I/O is the performance bottleneck, that usually means it's not Ruby related! Instead, I/O problems are frequently a language-agnostic set of
by jez 5y ago
At the point where I/O is the performance bottleneck, that usually means it's not Ruby related!
Instead, I/O problems are frequently a language-agnostic set of problems, like:
- Oh jeez, I'm making a database roundtrip 2x more frequently than I'd like to! Maybe I should change my application to batch the database requests.
- Oh jeez, I'm running on cheaper EC2 instances without SSDs, maybe I should upgrade!
etc.
- notpachet 5y agoI've actually found that a lot of I/O bottlenecks are often Ruby related, for the fact that Ruby doesn't give you a lot of great options in terms of doing that I/O in a non-blocking way. If your Ruby program has to do things like fetch data from upstream via a network request, you have to be very careful not to cause request saturation / queueing if that upstream request starts timing out. Even a well-behaving upstream can cause problems if your user patterns require you to hit it a lot. Shopify was fortunate that we had a lot of spare money flying around and could just scale the shit out of things horizontally, but that's a crude solution. Granted, there's been a lot of interesting work done on Ruby concurrency lately, but it's far from a solved problem at the language level. (background: former Shopify EM)