High-performance REST API - Which language/stack?

问题:

I am developing a site using Ruby on Rails. I would like to develop the REST API (JSON) separately to maximize performance, the Rails stack just takes away too much.

Are there any performance benchmarks out there? What do you think would yield the best performance? I am currently thinking about the following, because that's what I have experience with. Is there anything else I should consider? It should be lightweight.

• node.js
• Scala Spray (http://spray.io/)
• Ruby Sinatra

Thanks!

回答1:

Summary: Maximize your performance as a developer. Use stack you know best. First make it work, then make it fast.

Are there any performance benchmarks out there?

There are all kinds of benchmarks out there. Let's say, node.js can handle 100k HPS (helloworlds per second) and Sinatra can only do 80k. What does it tell you? Nothing.

Also, sometimes higher performance comes at a great cost. Take ruby C extensions, for example. Sure, C runs faster than Ruby, but it prevents other threads from running on other cores (because of GIL).

So, don't choose tech only by benchmark figures from the internet. There are so many factors to consider besides raw HPS number.

LINK: If you think Rails is too heavy, you should try rails-api. It's basically a stripped down version of Rails (you don't need things like cookie authentication or MSIE rendering helpers in an api server).

---

Personal story

I run an API server that handles some load. First version was written with Rails. Then I thought "Hey, Rails Is Bloated (c), let's rewrite everything with Sinatra". And then I had waves of frustration coming one after another. It turned out that Rails does a lot of small but helpful things which I didn't appreciate. I gave up, rewrote it with Rails again (applying lessons learned) and lived happily ever since.

回答2:

This falls into the 'should I rewrite my apache/php site in C with a customized webserver because it's slow' bucket.

I vote for picking your favorite stack to work in and utilize good caching and using whatever opcode optimization you've available if your code isn't compiled. Then make sure you've got adequate server resources and load balance horizontally if needed to handle the traffic.

I've yet to see many API's whose primary reason for poor performance is the choice of technology stack unless they're handling facebook/twitter size traffic or doing computationally intensive work.

You'll see in just about any stack you choose if properly utilized more latency occur in:

1. Transport of unnecessarily large amounts of data to the client
2. Performance hits due to poor SQL or other data source fetching slowness

I'd also highly recommend if you're already using a RoR stack to stick with it. Trying to optimize and code in different stacks will generally result in weaker code in both--keep your dev's brains focused in one pool of futz at a time.

回答3:

It really depends on your usecases and team experience/preferences - BUT, if you are truly open-ended about whatever stack, our personal experience was:

• Scala + Scalatra + Jetty was simple and very fast.
• Node + Express was surprisingly close in speed - but with the benefit (in our case) of flexible Javascript code.
• Ruby was much less performant than either, but had cool code.

Scala was a winner because our shop has lots of experience in the JVM. Hoever, we hope to leverage node more in the future do to the simplicity.

I'm sure experienced Ruby guys could do improve and tune things, but it wasn't worth the learning-curve for us and a non-starter.

回答4:

Check out spray -- I like it because it is lightweight and well-designed (modular, asynchronous, sane API). For web service stuff most web frameworks just come with too much baggage.