Re: [therubyracer] Performance and scalability in a production setting

[Charles Lowell]

On Aug 3, 2012, at 7:32 PM, Spike wrote:

Hi therubyracer community,

At Airbnb we're trying to solve the age-old problem of sharing templates and view logic between client and server, using Handlebars.  We're debating between two solutions:

Hi Spike. I use therubyracer for exactly this purpose on three production systems, however none with the scale of traffic that you see on airbnb, so I cannot speak to that very important concern.

1) Use therubyracer to embed V8 into the Ruby process.
2) Build a Node web service that Rails communicates with over HTTP.

We're leaning towards the web service approach because seems like it would allow for better scalability and maintainability, and the idea of embedding V8 into our Rails process scares our sysops guys.  But, using therubyracer would allow us to get this feature up and running much more quickly, and it appears to be a simpler solution.

Maybe I'm missing something, but requiring the overhead of a network call just in order to render a template does not seem inherently more scalable. In fact, unless you're very careful, it sounds to me like quite the opposite: a scalability and maintenance nightmare.

Do you have any insights into therubyracer performance in a production environment?  Are there any examples of high-traffic apps serving requests that hit therubyracer?  Any tips to decrease memory footprint?  Other gotchas?

I have found it to be very fast indeed, but it does use lots of memory by default. Keep in mind that V8 is a virtual machine, just like Java and just like Ruby and the out-of-the-box GC config for V8 is optimized for running Chrome on a desktop.  It's no surprise then that it will do things like grow its heap to 1.5G before even attempting to garbage collect. This can of course be remedied, but it's something you may need to do. That said, I've found that once my handlebars templates are compiled, memory growth is actually very slow and rendering is inexpensive.

I would only use 0.11 release series (currently in beta) It addresses a number of stability concerns as well as exposes a much larger swath of the underlying V8 api. This means that you can do things like tune the V8 garbage collector to put hard caps on the memory it will use or to limit how large of a javascript stack it will allow. To do this you still need to call the (undocumented) V8 metal, but this was previously impossible from Ruby. It also makes it easier to deal with cycles of garbage by having an explicit option to destroy javascript contexts. Note that this is not even a problem if you re-use javascript context for rendering (which I recommend).

Also, you may encounter problems building and deploying that can be a headache. I have enough time to make sure that it works smoothly on the systems I use (osx 10.6, 10.7, linux x64, heroku) and to answer questions about how the build system works, but if you use different systems than I do, you may find yourself having to debug makefiles for both V8 and therubyracer.

I would not currently use it in a multi-threaded environment where you have more than one thread rendering templates. This is not the standard architecture of most rails applications which have a single process per request and so has not been a problem for us.

Finally, there are most probably hidden crashes lurking somewhere that you will run into. I would like The Ruby Racer to become that system that is rock solid, and that the community can depend on, but that is not a claim I feel comfortable making today. To that end, I would be eager to work with you to work out problems you do run into, but it is something you should take into consideration.

I don't want to scare you off. In fact, I wrote therubyracer precisely so that we can use it for scenarios like these, but you would very much be an early adopter with all the risk/reward that it implies. I hope this information makes you feel more empowered to make the best decision for you and your development team.

cheers,

Charles

Thanks for the help.  I couldn't find any of this information on the web, so I hope this may be useful to tons of programmers

Thanks,
Spike

Charles Lowell 

thefrontside.net | twitter: @cowboyd | github: cowboyd

(p) +1.512.207.0229 (f) +1.512.374.0777

[Spike]

Charles,

Thanks for this amazing response.  This will certainly help us decide if we can take on the risk.

Cheers,

Spike

On Friday, August 3, 2012 5:32:05 PM UTC-7, Spike wrote:

Hi therubyracer community,

At Airbnb we're trying to solve the age-old problem of sharing templates and view logic between client and server, using Handlebars.  We're debating between two solutions:

1) Use therubyracer to embed V8 into the Ruby process.

2) Build a Node web service that Rails communicates with over HTTP.

We're leaning towards the web service approach because seems like it would allow for better scalability and maintainability, and the idea of embedding V8 into our Rails process scares our sysops guys.  But, using therubyracer would allow us to get this feature up and running much more quickly, and it appears to be a simpler solution.

Do you have any insights into therubyracer performance in a production environment?  Are there any examples of high-traffic apps serving requests that hit therubyracer?  Any tips to decrease memory footprint?  Other gotchas?

Thanks for the help.  I couldn't find any of this information on the web, so I hope this may be useful to tons of programmers.

Thanks,
Spike