4 ms·

Yes, well, that's a nice idea in theory. In practice, you could get over 10x (sometimes 100x) the rps off a box running the new, JVM-based services vs their Rai

by sulam 8y ago

Yes, well, that's a nice idea in theory. In practice, you could get over 10x (sometimes 100x) the rps off a box running the new, JVM-based services vs their Rails-equivalents. Orders of magnitude probably matter a little less when you're well-funded and have hundreds of servers, but when you are thinking about trying to go public and your bottom line is being scrutinized and you have 10's of thousands of servers, it starts to matter.

scarface74 8y ago
That's exactly what he said. but a well-capitalized company can certainly afford them But these days when you don't have to buy servers and make a long term capital commitment and you can use something like AWS, if you have a scalable but not efficient architecture and you have the faith of the investors, you can get enough servers to get you over the hump temporarily, slowly start replacing the most performance sensitive part of your architecture and then scale down. Look at what HN darling Dropbox did, they bootstrapped on AWS, got big and then when the time was right, they moved to a cheaper architecture - off of AWS and built their own infrastructure.
- sulam 8y ago
  And this is exactly what Twitter did, and how Twitter replaced Ruby and Rails with the JVM.
  - scarface74 8y ago
    I doubt they just "replaced" Ruby on Rails with the JVM without making any architectural changes based on the lessons they learned from thier first implementations.
    - sulam 8y ago
      Did I say that? We (I spent 4.5 years there, starting with the writing of the first service extracted from the monorail and left shortly before the 'twitter' repo was deleted) absolutely went through a huge architectural transition, arguably multiple transitions. The biggest was the breakup of the monolithic Rails-based application into microservices running on the JVM. These services generally scaled ten to one hundred times better than the code they replaced. (By "scaled" here I specifically mean that RPS was 10-100X higher per physical machine for services on the JVM as compared to the RPS the Rails stack could handle before falling over).
      - scarface74 8y ago
        I was replying to this: And this is exactly what Twitter did, and how Twitter replaced Ruby and Rails with the JVM In the context of my original post where the contention was that languages don't scale that architectures do. Your post was that it was exactly what you did - replaced Ruby with Java. Not that you replaced Ruby with Java and rearchitected the entire stack - exactly what my original post said waa the problem with Twitter - the architecture.
        sulam 8y ago
        Well, that's true to a degree, but only to a degree. If I wrote my database in Ruby, it would be slow compared to the same database written in C++ (assuming equivalent competency in the developers and equivalent architecture). Even a database written in Java benchmarks slower than the same database with the same architecture written in C/C++. Of course architectural changes can make further improvements. To the point of Twitter, what we _didn't_ do, despite a lot of Ruby expertise on the team, is write a lot of microservices in Ruby. The reason for that is that I don't think you can get the same RPS out of a Ruby service that you can out of a JVM service, all else being equal. In fact HTTP benchmarks for various platforms show this, if you bother to look.
        scarface74 8y ago
        I'm not disagreeing with you. Looking on the outside, Twitter had two issues. 1. Twitter wasn't built on a scalable architecture 2. Ruby didn't use resources efficiently -- it was slower than other stacks. If Twitter had been scalable, even if it were 10x slower than Java, you could throw 10x the number of servers at it until you optimized the stack then reduce the number of servers needed and the customers would have been none the wiser. Of course the investors wouldn't have been happy. Well at least in today's world. I don't know what the state of cloud services were in 2008. Then you could focus on efficiency. But since Twitter wasn't scalable, you had to fix the stack while the customers were effected. I'm almost sure even in 2008, with the growth of Twitter they could have gotten the capital to invest in more servers if they needed them. It's not completely analogous but Dropbox is a good counterexample. Dropbox was hosted on AWS at first. Dropbox never had to worry about running out of storage space no matter how big it grew (it had a scalable architecture) but for their use case, they weren't as efficient (ie cost not computer resources). Their customers were never affected by their lack of efficiency because they could operate at scale. They had breathing room to re-architect a more efficient solution.
realusername 8y ago
Rails strength isn't the speed of it's code but it's speed of development, the JVM-based service equivalent you are comparing it with probably needs 5x the amount of engineering time to build the same as what you have for free with Rails. (which also needs to be included in the engineering costs)
- scarface74 8y ago
  I doubt that any language gives you 5x the productivity of another language. I don't think I would be 5x slower writing a Back end web code in C than I would in C# and C is probably the worse language to do an API in.
  - realusername 8y ago
    It's not about the language, it's about the batteries-included mindset of rails. You have your nice web framework in X language and then you need something else quickly is already built-in in Rails or a very powerful feature that in Rails you could just install a gem and call it a day. I'm working with Express/Node now, I've worked with Symfony/Laravel in php, I've worked with Django in Python, I like them all but there's nothing which can truly replace the speed of coding with Rails.
- segmondy 8y ago
  Rails speed is speed of prototype. When you have a sufficiently large system with Rails, your development slows down. This is not just so for Rails, but languages like PHP, Python, Javascript.
ksec 8y ago
10x, Sure, possible. 100x? Most of the problem lies in Database. Rails may not be best architecture for scale. But I doubt you could even get 100x difference if the bottleneck is in Database. I don't know any large, JVM based WebSite in large scale on top of my head, but I consider Stackoverflow, written in ASP.NET to be one of the best and most optimised site. Near 700M Pageview per month, with 10 Front End Servers. At peak it does close to 5000 RPS, Cookpad does 15,000 RPS with 300 Rails Server. But the SO servers are at least twice as powerful, so that scale is like 500 RPS / Server to 100RPS / Server. 5x Difference.
- sulam 8y ago
  You're making the assumption that there is a database in the mix for the 100X case. There wasn't, except in-memory. It wasn't a 100X improvement across the board, it was 10X to 100X.
  - jashmatthews 8y ago
    Did Twitter ever upgrade past Ruby 1.8? If not these numbers won't be particularly relevant to modern Ruby. (for anyone else reading 1.8 was a simple interpreter and 1.9+ a modern high-performance bytecode VM)
- tmd83 8y ago
  Does SO probably has a lot more cacheable content and their core content size is small < 2TB full DB size with DB memory hitting 768GB or so. Not that it doesn't require good engineering. I do love their stats.
segmondy 8y ago
Only if you look at these ridiculous benchmarks serving "hello world" and json encoding/decoding a basic dataset. The real limits to scale is I/O. CPU I/O, Storage I/O, Network I/O. JVM doesn't give you an edge on it. Once your app starts doing useful non localized work, the advantage of JVM is 2-3x at best.
- sulam 8y ago
  No, I'm looking at Twitter's numbers in production. Before and after very much tells the tale -- and it was mostly the same engineers, so it wasn't "oh well you had the B team doing Rails and the A team doing JVM code" or whatever other excuse you want to look for. Microbenchmarks aren't the end-all-be-all, but you see the same story there.

by sulam 8y ago

scarface74 8y ago

That's exactly what he said. but a well-capitalized company can certainly afford them But these days when you don't have to buy servers and make a long term capital commitment and you can use something like AWS, if you have a scalable but not efficient architecture and you have the faith of the investors, you can get enough servers to get you over the hump temporarily, slowly start replacing the most performance sensitive part of your architecture and then scale down. Look at what HN darling Dropbox did, they bootstrapped on AWS, got big and then when the time was right, they moved to a cheaper architecture - off of AWS and built their own infrastructure.

sulam 8y ago
And this is exactly what Twitter did, and how Twitter replaced Ruby and Rails with the JVM.
- scarface74 8y ago
  I doubt they just "replaced" Ruby on Rails with the JVM without making any architectural changes based on the lessons they learned from thier first implementations.
  - sulam 8y ago
    Did I say that? We (I spent 4.5 years there, starting with the writing of the first service extracted from the monorail and left shortly before the 'twitter' repo was deleted) absolutely went through a huge architectural transition, arguably multiple transitions. The biggest was the breakup of the monolithic Rails-based application into microservices running on the JVM. These services generally scaled ten to one hundred times better than the code they replaced. (By "scaled" here I specifically mean that RPS was 10-100X higher per physical machine for services on the JVM as compared to the RPS the Rails stack could handle before falling over).
    - scarface74 8y ago
      I was replying to this: And this is exactly what Twitter did, and how Twitter replaced Ruby and Rails with the JVM In the context of my original post where the contention was that languages don't scale that architectures do. Your post was that it was exactly what you did - replaced Ruby with Java. Not that you replaced Ruby with Java and rearchitected the entire stack - exactly what my original post said waa the problem with Twitter - the architecture.
      - sulam 8y ago
        Well, that's true to a degree, but only to a degree. If I wrote my database in Ruby, it would be slow compared to the same database written in C++ (assuming equivalent competency in the developers and equivalent architecture). Even a database written in Java benchmarks slower than the same database with the same architecture written in C/C++. Of course architectural changes can make further improvements. To the point of Twitter, what we _didn't_ do, despite a lot of Ruby expertise on the team, is write a lot of microservices in Ruby. The reason for that is that I don't think you can get the same RPS out of a Ruby service that you can out of a JVM service, all else being equal. In fact HTTP benchmarks for various platforms show this, if you bother to look.
        scarface74 8y ago
        I'm not disagreeing with you. Looking on the outside, Twitter had two issues. 1. Twitter wasn't built on a scalable architecture 2. Ruby didn't use resources efficiently -- it was slower than other stacks. If Twitter had been scalable, even if it were 10x slower than Java, you could throw 10x the number of servers at it until you optimized the stack then reduce the number of servers needed and the customers would have been none the wiser. Of course the investors wouldn't have been happy. Well at least in today's world. I don't know what the state of cloud services were in 2008. Then you could focus on efficiency. But since Twitter wasn't scalable, you had to fix the stack while the customers were effected. I'm almost sure even in 2008, with the growth of Twitter they could have gotten the capital to invest in more servers if they needed them. It's not completely analogous but Dropbox is a good counterexample. Dropbox was hosted on AWS at first. Dropbox never had to worry about running out of storage space no matter how big it grew (it had a scalable architecture) but for their use case, they weren't as efficient (ie cost not computer resources). Their customers were never affected by their lack of efficiency because they could operate at scale. They had breathing room to re-architect a more efficient solution.

realusername 8y ago

Rails strength isn't the speed of it's code but it's speed of development, the JVM-based service equivalent you are comparing it with probably needs 5x the amount of engineering time to build the same as what you have for free with Rails. (which also needs to be included in the engineering costs)

scarface74 8y ago
I doubt that any language gives you 5x the productivity of another language. I don't think I would be 5x slower writing a Back end web code in C than I would in C# and C is probably the worse language to do an API in.
- realusername 8y ago
  It's not about the language, it's about the batteries-included mindset of rails. You have your nice web framework in X language and then you need something else quickly is already built-in in Rails or a very powerful feature that in Rails you could just install a gem and call it a day. I'm working with Express/Node now, I've worked with Symfony/Laravel in php, I've worked with Django in Python, I like them all but there's nothing which can truly replace the speed of coding with Rails.
segmondy 8y ago
Rails speed is speed of prototype. When you have a sufficiently large system with Rails, your development slows down. This is not just so for Rails, but languages like PHP, Python, Javascript.

ksec 8y ago

10x, Sure, possible. 100x? Most of the problem lies in Database. Rails may not be best architecture for scale. But I doubt you could even get 100x difference if the bottleneck is in Database. I don't know any large, JVM based WebSite in large scale on top of my head, but I consider Stackoverflow, written in ASP.NET to be one of the best and most optimised site. Near 700M Pageview per month, with 10 Front End Servers. At peak it does close to 5000 RPS, Cookpad does 15,000 RPS with 300 Rails Server. But the SO servers are at least twice as powerful, so that scale is like 500 RPS / Server to 100RPS / Server. 5x Difference.

sulam 8y ago
You're making the assumption that there is a database in the mix for the 100X case. There wasn't, except in-memory. It wasn't a 100X improvement across the board, it was 10X to 100X.
- jashmatthews 8y ago
  Did Twitter ever upgrade past Ruby 1.8? If not these numbers won't be particularly relevant to modern Ruby. (for anyone else reading 1.8 was a simple interpreter and 1.9+ a modern high-performance bytecode VM)
tmd83 8y ago
Does SO probably has a lot more cacheable content and their core content size is small < 2TB full DB size with DB memory hitting 768GB or so. Not that it doesn't require good engineering. I do love their stats.

segmondy 8y ago

Only if you look at these ridiculous benchmarks serving "hello world" and json encoding/decoding a basic dataset. The real limits to scale is I/O. CPU I/O, Storage I/O, Network I/O. JVM doesn't give you an edge on it. Once your app starts doing useful non localized work, the advantage of JVM is 2-3x at best.

sulam 8y ago
No, I'm looking at Twitter's numbers in production. Before and after very much tells the tale -- and it was mostly the same engineers, so it wasn't "oh well you had the B team doing Rails and the A team doing JVM code" or whatever other excuse you want to look for. Microbenchmarks aren't the end-all-be-all, but you see the same story there.