Live data from Hacker News

Twitter: From Ruby on Rails to the JVM [video]

ontwik.com

41–50 of 95 posts

Re: Twitter: From Ruby on Rails to the JVM [video]

#41
post #25
post #16

Earlier quoted context omitted.

Shopify is still 100% ROR and we serve hundreds of millions of requests. You will be fine :-) It's a competitive advantage for us, we move faster then the rest of the market.

I'm actually really glad to hear it. Though, I wonder about the "rails doesn't scale" mantra, is that really more for active record? In your experience is active record the biggest out of the box bottleneck?

We handle a lot less traffic than Shopify (~15-20 million reqs a day) but ActiveRecord isn't a bottleneck and I wouldn't expect to to be [...unless you are talking about something other than the performance of AR as a body of code?]

Instead of "Rails doesn't scale" we should say "Rails runs on Ruby which means that it will consume significantly more CPU and more memory* compared to something else"

In my case, 1 extra server (my estimate) was a small price to pay for developer happiness.

* unless you are running JRuby

Re: Twitter: From Ruby on Rails to the JVM [video]

#42

I was recently in a quandary over the choice of technology. I started RoR and I really like it. However I was concerned about long term implications of that choice. The thing that I am taking from this talk is that I shouldn't worry about that, right now. If and when I need to scale, I will have enough resources to make a better choice. Resources that I don't have right now.

I'm working at a company right now that have a very big Rails stack. Hundreds of models, probably thousands of files (not including plugins and gems) across the whole app. They are experiencing scaling issues but not for requests per second, but for developer productivity.

I'm reading a great book called Service-Oriented Design with Ruby and Rails, by Paul Dix. He states a lot of the issues that our team is running into with a monolithic app. Seems also that these issues can apply to other frameworks outside of Rails (I've run into some of these same issues years ago with Java web apps).

The main point of the book is figuring out how to abstract out various layers of the app into standalone services. I've talked to people about this and a lot of the time they recoil at the fact that you would increase the complexity of the app by adding yet more parts (services) that require separate machines, deployment dependencies, and their own data stores. However, looking at big sites like Amazon or Twitter shows how one needs and can break apart their systems to make it easier for developers to focus on particular pieces as well as increase system performance.

I'm going to be joining a new startup this year as the technology lead and all these things are on the table. I'm evaluating node, some NoSQL dbs, some cloud paas', etc. I'm also going to be designing from the beginning fast fail and services - or at least an architecture that makes it fairly easy to start migrating parts of the system over to their own standalone services should the need arise. I don't think you can plan for everything, but with the way technology is moving forward and the tools available today, you need to keep SOA at least in the back of your mind.

Re: Twitter: From Ruby on Rails to the JVM [video]

#44
post #8

Earlier quoted context omitted.

JRuby is fast for a Ruby implementation, but it's still far, far slower than Scala or Java itself. http://shootout.alioth.debian.org/u32/benchmark.php?test=all...

I do get that a dynamic language like Ruby will always be slower than a language like Java, which has primitives and where many things, including static method calls, are solved at compile time. But citing the Alioth.Debian benchmarks? Really? Dude, take a look at the source-code of those benchmarks sometimes -- they are completely useless ;)

They're as useful as the code is well written for each language.

You think the Ruby code could be faster, and thus the comparison is skewed? Go ahead and help everyone understand by improving it.

Re: Twitter: From Ruby on Rails to the JVM [video]

#46

Earlier quoted context omitted.

You will get your app of the ground faster, but you're selling yourself short if you're a technology-based company thinking that you'll never have scaling problems. Competing against Twitter or any other social-based app you'll probably never encounter that level of scale, but any financial application will need to be both fast and handle the complexities that only the JVM can address. Like he states at the end of th…

I'm pretty sure he said "4x" rather than "Forex".

Good catch, and make sense given the context. My mind is stuck in HFT mode and constantly has me worried.

Re: Twitter: From Ruby on Rails to the JVM [video]

#47
post #25
post #16

Earlier quoted context omitted.

Shopify is still 100% ROR and we serve hundreds of millions of requests. You will be fine :-) It's a competitive advantage for us, we move faster then the rest of the market.

I'm actually really glad to hear it. Though, I wonder about the "rails doesn't scale" mantra, is that really more for active record? In your experience is active record the biggest out of the box bottleneck?

The "rails doesn't scale" mantra was discredited 5 years ago, when people realised that it scales exactly the same way as PHP. Remember, scalability != performance.

Re: Twitter: From Ruby on Rails to the JVM [video]

#48
post #16

Earlier quoted context omitted.

Shopify is still 100% ROR and we serve hundreds of millions of requests. You will be fine :-) It's a competitive advantage for us, we move faster then the rest of the market.

Well, correct me if I'm wring but Shopfiy is a completely different scaling problem from Twitter. As I understand it Shopify's individual hosted stores are pretty much self-contained. So you can pretty much stick each one on it's own server with it's own database and it'll be fine. Twitter accounts all have to be able to talk to eachother in real time so you can't do that. My current startup has a Shopify-like archit…

> So you can pretty much stick each one on it's own server with it's own database and it'll be fine.

That is not a scalable solution. Yes, it'll get you up and running out of the box, but as you keep spinning up servers to host each store and it's database you'll have to keep adding exponential resources (hardware, software, meatware) to the problem and keep you from achieving economies of scale.

Re: Twitter: From Ruby on Rails to the JVM [video]

#49

Earlier quoted context omitted.

Well, correct me if I'm wring but Shopfiy is a completely different scaling problem from Twitter. As I understand it Shopify's individual hosted stores are pretty much self-contained. So you can pretty much stick each one on it's own server with it's own database and it'll be fine. Twitter accounts all have to be able to talk to eachother in real time so you can't do that. My current startup has a Shopify-like archit…

> So you can pretty much stick each one on it's own server with it's own database and it'll be fine. That is not a scalable solution. Yes, it'll get you up and running out of the box, but as you keep spinning up servers to host each store and it's database you'll have to keep adding exponential resources (hardware, software, meatware) to the problem and keep you from achieving economies of scale.

Yes, its not an ideal solution for the long term, but its something easy you can do to scale quickly if you have this architecture. It'll make sure your site stays up.

Afterwards, you can spend the time doing it properly when things have calmed down a little.

That's a lot easier than scaling something like Twitter.

Re: Twitter: From Ruby on Rails to the JVM [video]

#50

I was recently in a quandary over the choice of technology. I started RoR and I really like it. However I was concerned about long term implications of that choice. The thing that I am taking from this talk is that I shouldn't worry about that, right now. If and when I need to scale, I will have enough resources to make a better choice. Resources that I don't have right now.

True that. Even LOLCODE can scale :) Twitter's problems are very specific to twitter - Mega throughput (~7000 Tweets per second) in realtime, sharded DBs requiring multiple connections etc.

Ruby will give you a significant time to market advantage especially if you are a startup.

Post reply on HN