Aaron Patterson on Rails 3.1 and Ruby Performance

1. I’m Obie Fernandez and I’m at RailsConf with Aaron Patterson, Tenderlove in the Ruby community and I don’t know your official position at AT&T. Maybe you can fill us in about what you officially do at AT&T.

I’ve worked for AT&T for over 2 years. I am an open-source developer for AT&T. I think my official title is just Senior Software Engineer, but what I do for them, basically what I do every day is just I work on the open-source tools that our developers use, in order to improve their productivity so that we can help our bottom line. If I help out all of our engineers that saves the company so much money and then obviously our performance improvements and stuff so that we can save money on hardware and things like that, too.

2. You have the distinction of being on Rails core and Ruby core committer and no one else has that particular.

Not yet. I’m a Rails core committer and Ruby core committer and I’m the first one and the only one so far.

3. Tell us a bit about the challenges that we’re facing with Rails 3.1 and performance.

Each release of Rails has been getting slower, but it’s not necessarily a bad thing. The reason it’s getting slower it’s because Rails is just doing more things that people need and if you do more work, obviously it takes longer time. But the problem is we’re getting to a point where we need to start examining that and kind of reigning it in. The main problem that I found recently is with the Rack stack that we have, the middleware that you come with by default, there is a lot and so what happens is that when a request comes in, the stack size before it gets to any user code like your controller code is very deep on regular Ruby on MRI, stack size greatly affects the garbage collector. So the larger the stack is the slower the garbage collector is.

Because we’ve increased the number of middleware, we’re increasing the GC time, which means that we’re slowing the process down. What I would like to do is decrease that size.

4. Are there any reasonable expectations that the garbage collector in MRI is going to get significantly better or have more modern options?

In Trunk Ruby, there is actually a lazy sweep garbage collector, so there is actually a brand-new garbage collector that’s going to be in Ruby 1.9.3 but it’s still a conservative garbage collector. It’s just conservative and lazy sweeping, so it turns out to be faster for systems that use a lot of objects, but slower for systems that use few objects. Most people use a lot of objects, so it will be faster.

5. Rails especially uses a lot of objects.

Yes. It will be faster in most cases.

6. What is the timeline from when we can see MRI start hitting some mainstream usage like the later versions of it?

1.9.3 - I have no idea, because I think the release plan is to have that out in August, but I don’t remember and then of course there is time for adoption and what not, so I don’t know.

7. In the meantime, do you think that a larger portion of the community is going to start just migrating over to Rubinius for production use?

I’m not sure. I think a better thing to answer is how to deal with this problem today, how to fix the problem that we have today or how can I take my application and reduce the request and response times. The best way to do that is either switch to a different VM like Rubinius or JRuby or switch to Ruby Enterprise Edition (with Ruby Enterprise Edition you can tweak the garbage collector such that the stack sizes don’t really matter so much) or switching to 1.9.2. 1.9.2 is still affected by the deep stack size, but just the fact that 1.9.2 is faster may be good enough. For the benchmarks that I ran, one MRI, stock 1.8.7 was about two times slower than 1.9.2 was, so I can process twice as many requests per second with 1.9.2 than I could with 1.8.7. The other thing you can do is just reduce middleware so your stack size isn't so big.

8. Rails 3 introduced a lot of abstractions and definitely it seems at least from a layman's view or a naive view of that that a lot of those abstractions are what’s causing the stack to increase. It feels like the team that’s working on really pushing the platform forward perhaps has some very interesting tradeoffs ahead of them. How do you go about deciding what to do about these?

I think that the middleware that’s been added that increases the stack size is necessary. We need to have these bits of code.

9. We’re talking about things like?

Connection pool handling, we have a request timer or etags - there are various things that are done in the middleware. They are all actually important things that need to happen. What we need to do is we need to figure out how to execute the same code, like be able to do the same work, but do it with smaller stack size. I think one of the biggest challenges with that is that we fundamentally need to change the Rack spec, that just needs to be changed. There is no way to get around it. That is a huge challenge.

10. You went into some of that in your keynote.

I think that the API needs to be completely changed and what will happen is we’ll have to change how our middleware is implemented and that’s a huge challenge, obviously. Changing all that code is a big deal, but I think we can do it in such a way that it’s backwards compatible. So people who have existing Rack applications can still use them just fine, but they’ll still have to pay this call stack price.

11. Does this perhaps start to illuminate where the future of Rails might be in terms of what is Rails for.

I don’t really think it’s going to change the direction too much of Rails, but I think it will make certain things easier, like doing asynchronous calls or doing streaming output, doing stuff with EventMachine definitely. Basically I think it will make building async apps inside of Rails much easier, but I think that’s the direction we have to go anyway. So, I’m not sure there is necessarily a change in direction.

12. There is no doubt, being at a conference like RailsConf you kind of see the evolution of the people who come to RailsConf and the growth of the community. Why, in your mind does Rails and Ruby stay relevant over the years? What keeps you interested in continuing to put that energy into it?

I love the Ruby language itself. It’s got everything I love, it just clicks in my brain very easily. I can do functional style stuff if I want to, it make OO insanely easy and it also has dynamic typing that I love, too. That’s why I continue to stay interested in it, but that doesn’t prevent me from researching other languages. I learn other languages in my free time, but as far as Rails staying relevant is concerned, I think it has some of the same characteristics, it has the same appeal to me that Ruby the language has. It’s easy to use, it does what I think it should do. It lacks in extensibility in some places, but that’s stuff I’m working on specifically.