Ruby on Rails 可扩展性/性能?

问题描述

我已经使用 PHP 一段时间了，并且很好地与 CodeIgniter 一起使用，这是一个很棒的框架.我正在开始一个新的个人项目，上次我考虑使用什么(PHP 与 ROR)时，我使用了 PHP，因为我听说 ROR 存在可扩展性问题，尤其是在阅读了 Twitter 开发人员对此的评论之后.可扩展性是否仍然是 ROR 中的一个问题，或者是否有改进?

I have used PHP for awhile now and have used it well with CodeIgniter, which is a great framework. I am starting on a new personal project and last time I was considering what to use (PHP vs ROR) I used PHP because of the scalability problems I heard ROR had, especially after reading what the Twitter devs had to say about it. Is scalability still an issue in ROR or has there been improvements to it?

我想学习一门新语言，ROR 似乎很有趣.PHP 完成了这项工作，但众所周知，它的语法和组织很糟糕，感觉就像是一次大黑客.

I would like to learn a new language, and ROR seems interesting. PHP gets the job done but as everyone knows its syntax and organization are fugly and it feels like one big hack.

推荐答案

稍微扩展 Ryan Doherty 的回答...

To expand on Ryan Doherty's answer a bit...

我在日常工作中使用静态类型语言 (.NET/C#)，同时使用 Ruby 作为副业.在我现在的日常工作之前，我是一家 ruby​​ 开发公司的首席程序员，为纽约时报辛迪加服务工作.在此之前，我也在 PHP 工作过(虽然很久很久以前).

I work in a statically typed language for my day job (.NET/C#), as well as Ruby as a side thing. Prior to my current day job, I was the lead programmer for a ruby development firm doing work for the New York Times Syndication service. Before that, I worked in PHP as well (though long, long ago).

我这么说只是为了说:我亲身体验过 Rails(更普遍的是 ruby​​)性能问题，以及其他一些替代方案.正如瑞安所说，你不会让它自动为你扩展.找到瓶颈需要工作和巨大的耐心.

I say that simply to say this: I've experienced rails (and more generally ruby) performance problems first hand, as well as a few other alternatives. As Ryan says, you aren't going to have it automatically scale for you. It takes work and immense amounts of patience to find your bottlenecks.

我们从其他人那里看到的大部分性能问题，甚至我们自己都在处理 ORM 层中执行缓慢的查询.我们从 Rails/ActiveRecord 到 Rails/DataMapper，最后到 Merb/DM，每次迭代都因为底层框架而获得更快的速度.

A large majority of the performance issues we saw from others and even ourselves were dealing with slow performing queries in our ORM layer. We went from Rails/ActiveRecord to Rails/DataMapper and finally to Merb/DM, each iteration getting more speed simply because of the underlying frameworks.

缓存为性能创造了惊人的奇迹.不幸的是，我们无法缓存我们的数据.我们的缓存最多每五分钟就会失效一次.我们网站的几乎每一点都是动态的.因此，如果/当您无法做到这一点时，也许您可​​以从我们的经验中学习.

Caching does amazing wonders for performance. Unfortunately, we couldn't cache our data. Our cache would effectively be invalidated every five minutes at most. Nearly every single bit of our site was dynamic. So if/when you can't do that, perhaps you can learn from our experience.

我们最终不得不认真地微调我们的数据库索引，确保我们的查询没有做非常愚蠢的事情，确保我们没有执行超过绝对必要的查询，等等.当我说非常愚蠢的事情"，我的意思是 1 + N 查询问题...

We had to end up seriously fine tuning our database indexes, making sure our queries weren't doing very stupid things, making sure we weren't executing more queries than was absolutely necessary, etc. When I say "very stupid things", I mean the 1 + N query problem...

#1 query
Dog.find(:all).each do |dog|
   #N queries
   dog.owner.siblings.each do |sibling|
      #N queries per above N query!!
      sibling.pets.each do |pet|
         #Do something here
      end
   end
end

DataMapper 是处理上述问题的极好方法(它没有 1 + N 问题)，但更好的方法是动用您的大脑并停止执行这样的查询 :D当您需要原始性能时，大多数 ORM 层不会轻易处理极其自定义的查询，因此您不妨手写它们.

DataMapper is an excellent way to handle the above problem (there are no 1 + N problems with it), but an even better way is to use your brain and stop doing queries like that :D When you need raw performance, most of the ORM layers won't easily handle extremely custom queries, so you might as well hand write them.

我们也做了一些常识性的事情.我们为不断增长的数据库购买了一个强大的服务器，并将其移到了自己的专用盒子上.我们还必须不断进行大量的处理和数据导入.我们也将我们的处理转移到它自己的盒子上.我们还停止为我们的数据导入实用程序加载整个该死的堆栈.我们只加载了我们绝对需要的东西(从而减少了内存开销！).

We also did common sense things. We bought a beefy server for our growing database, and moved it off onto it's own dedicated box. We also had to do TONS of processing and data importing constantly. We moved our processing off onto its own box as well. We also stopped loading our entire freaking stack just for our data import utilities. We tastefully loaded only what we absolutely needed (thus reducing memory overhead!).

如果您还不能确定……一般来说，当涉及到 ruby​​/rails/merb 时，您必须向外扩展，将硬件放在问题上.但归根结底，硬件便宜；虽然这不是劣质代码的借口！:D

If you can't tell already... generally, when it comes to ruby/rails/merb, you have to scale out, throwing hardware at the problem. But in the end, hardware is cheap; though that's no excuse for shoddy code! :D

即使有这些困难，如果我能帮上忙，我个人也绝不会在另一个框架中开始项目.我爱上了这门语言，并且每天都在不断地了解它.这是我无法从 C# 中得到的东西，尽管 C# 更快.

And even with these difficulties, I personally would never start projects in another framework if I can help it. I'm in love with the language, and continually learn more about it every day. That's something that I don't get from C#, though C# is faster.

我也喜欢开源工具、开始使用该语言的低成本、将一些东西放在那里并尝试看看它是否有市场的低成本，同时使用一种经常可以使用的语言工作优雅美丽...

I also enjoy the open source tools, the low cost to start working in the language, the low cost to just get something out there and try to see if it's marketable, all the while working in a language that often times can be elegant and beautiful...

最后，在选择框架时，您日复一日地想要生活、呼吸、饮食和睡眠是什么.如果您喜欢 Microsoft 的思维方式，请选择 .NET.如果您想要开源但仍然想要结构，请尝试 Java.如果你想拥有一门动态语言并且仍然比 ruby​​ 有更多的结构，请尝试 python.如果你想要优雅，试试 Ruby(我开玩笑，我开玩笑……还有许多其他优雅的语言适合这个要求.不要试图开始一场火焰战争:D)

In the end, it's all about what you want to live, breathe, eat, and sleep in day in and day out when it comes to choosing your framework. If you like Microsoft's way of thinking, go .NET. If you want open source but still want structure, try Java. If you want to have a dynamic language and still have a bit more structure than ruby, try python. And if you want elegance, try Ruby (I kid, I kid... there are many other elegant languages that fit the bill. Not trying to start a flame war :D)

见鬼，都试试！我倾向于同意上面的答案，即早期担心优化并不是您应该或不应该选择框架的原因，但我不同意这是他们唯一的答案.

Hell, try them all! I tend to agree with the answers above that worrying about optimizations early isn't the reason you should or shouldn't pick a framework, but I disagree that this is their only answer.

简而言之，是的，您必须克服一些困难，但恕我直言，语言的优雅远远超过了这些缺点.

So in short, yes there are difficulties you have to overcome, but the elegance of the language, imho, far outweighs those shortcomings.

对不起，小说，但我一直在那里和性能问题.它可以被克服.所以不要让它吓到你.

Sorry for the novel, but I've been there and back with performance issues. It can be overcome. So don't let that scare you off.

这篇关于Ruby on Rails 可扩展性/性能?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！