Rails Metal(&Rack)是实现高流量Web服务API的好方法吗？

Question

我正在开发一个非常典型的Web应用程序.用户体验的主要组成部分是网站所有者将在其首页上安装的小部件.每次加载首页时,小部件都会与我们的服务器通信并显示一些返回的数据.

因此,此Web应用程序有两个组件:

1. 站点所有者用于配置其窗口小部件的前端UI
2. 响应窗口小部件的web api调用的后端组件

以前我们用PHP运行所有这些.现在我们正在尝试使用Rails,这对于#1(前端UI)来说非常棒.问题是如何高效地执行#2,即小部件信息的后台服务.显然,这比前端负载要高得多,因为每次首页加载到我们客户的网站上时都会调用它.

我可以看到两种明显的方法:

A. 并行堆栈:建立一个使用除rails之外的其他东西的并行堆栈(例如我们旧的基于PHP的方法),但访问与前端相同的数据库

B. Rails Metal:使用Rails Metal/Rack绕过Rails路由机制,但是在Rails应用程序中保持api调用响应者

我的主要问题:

1. Rails/Metal是一种合理的方法吗？

但是也...

2. 加载Rails环境的开销是否仍然过重？
3. 是否有办法通过Rails更接近金属,绕过大部分环境？
4. Rails/Metal性能是否会在直接PHP上完成类似的任务(只是在这里寻找球场)？

和...

5. 是否有一个'C'选项比A和B都要好得多？也就是说,在将C代码编译为二进制并安装为nginx或apache模块之前,有什么东西？

提前感谢任何见解.

Answer 1

如果我确定了遇到的任何性能问题的确切原因，我只会开始将功能下拉到 Rack/Metal。特别是在最新版本的 Rails（尤其是 3）和 Ruby 中，堆栈本身很少成为瓶颈。开始测量，获取一些真实的指标并明智地优化。

我的经验法则：如果你没有指标，你就无法智能地推理你的性能问题和任何可能的解决方案。

根据我的经验，问题几乎总是：视图和数据库。

正如 Ryan 所建议的，缓存可以非常有效……您甚至可以移动您的架构，在 Rails 请求堆栈前面使用反向代理，以提供更多功能。像 Varnish 这样的缓存提供了令人难以置信的高性能。Rails 内置了对 etag 和 HTTP 标头的支持，以促进反向代理解决方案。

要做的另一件事是查看数据库层本身。缓存在这里可以发挥很大作用，但一些优化在这里也可能有用。确保明智地使用 Active Record 的 :include 是避免 N+1 查询情况的重要一步，但 Rails 提供了出色的支持，只需很少的配置或无需配置即可将 memcached 放入堆栈中，这可以提供出色的性能增益。