3 ms·

I guess the more interesting data point is not how many queries it served but a what the cost was for serving them.

by jamil7 3y ago

pmontra 3y ago
Ultimately the interesting thing to know is why they decided to stay on Rails instead of rewriting everything in a more performant language.
- aaronbrethorst 3y ago
  Joel Spolsky wrote about it, actually: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- ericb 3y ago
  CPU cost is the obvious driver of who will win in this space, ergo, the correct optimization is to rewrite in assembly.
- iimblack 3y ago
  Don’t they also have a ton of custom ruby stuff like their own jit?
  - campbel 3y ago
    They employee the creator of yjit https://shopify.engineering/yjit-just-in-time-compiler-cruby https://shopify.engineering/yjit-just-in-time-compiler-cruby
  - riffraff 3y ago
    Shopify did develop a jit, but it's part of the main ruby runtime (they did other performance improvement too, all available in the standard ruby).
- abhibeckert 3y ago
  Modern CPUs are fast, and it's trivial to scale compute instances if you need that. The database would be the bottleneck and that's got nothing to do with rails - it's all mysql.
ajmurmann 3y ago
That they can solve it at all is critical information. One could have expected the stack to not be able to horizontally scale this far. You are right though, that there is also a question of a trade-off between hosting cost on one and and the developer hours, risk, opportunity cost and lower hosting cost that come with a rewrite on the other for which one would need to know hosting cost among other critical factors.
TheRealDunkirk 3y ago
I love it. Apologies if you didn't mean it this way, but given the usual context of this forum, the insinuation here is so clever: Imply that it takes significantly more "compute" costs for a Rails platform, as opposed to what it would take if it were running on something "more performant," say, Java, and the JS front end flavor of the week. I would argue that the computing costs of any computing endeavor (short of AI, at this point) are dwarfed by the human costs, and my personal experience is that Ruby/Rails is at least a 10x headcount savings over the programmer sprawl required for Java/JS. Java and JS sure are good for job security. I'll give them that. Throw in an unequivocal demand for Oracle, and Cisco networking gear, and you have the whole Fortune 500 world that got dumped on us from the people who couldn't manage the mainframes, either.

I guess the more interesting data point is not how many queries it served but a what the cost was for serving them.

by jamil7 3y ago

I guess the more interesting data point is not how many queries it served but a what the cost was for serving them.

Ultimately the interesting thing to know is why they decided to stay on Rails instead of rewriting everything in a more performant language.

aaronbrethorst 3y ago
Joel Spolsky wrote about it, actually: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
ericb 3y ago
CPU cost is the obvious driver of who will win in this space, ergo, the correct optimization is to rewrite in assembly.
iimblack 3y ago
Don’t they also have a ton of custom ruby stuff like their own jit?
- campbel 3y ago
  They employee the creator of yjit https://shopify.engineering/yjit-just-in-time-compiler-cruby https://shopify.engineering/yjit-just-in-time-compiler-cruby
- riffraff 3y ago
  Shopify did develop a jit, but it's part of the main ruby runtime (they did other performance improvement too, all available in the standard ruby).
abhibeckert 3y ago
Modern CPUs are fast, and it's trivial to scale compute instances if you need that. The database would be the bottleneck and that's got nothing to do with rails - it's all mysql.

ajmurmann 3y ago

That they can solve it at all is critical information. One could have expected the stack to not be able to horizontally scale this far. You are right though, that there is also a question of a trade-off between hosting cost on one and and the developer hours, risk, opportunity cost and lower hosting cost that come with a rewrite on the other for which one would need to know hosting cost among other critical factors.

TheRealDunkirk 3y ago

I love it. Apologies if you didn't mean it this way, but given the usual context of this forum, the insinuation here is so clever: Imply that it takes significantly more "compute" costs for a Rails platform, as opposed to what it would take if it were running on something "more performant," say, Java, and the JS front end flavor of the week. I would argue that the computing costs of any computing endeavor (short of AI, at this point) are dwarfed by the human costs, and my personal experience is that Ruby/Rails is at least a 10x headcount savings over the programmer sprawl required for Java/JS. Java and JS sure are good for job security. I'll give them that. Throw in an unequivocal demand for Oracle, and Cisco networking gear, and you have the whole Fortune 500 world that got dumped on us from the people who couldn't manage the mainframes, either.