ruby-on-rails - Rails 请求初始化

Question

我们都听说过很多关于 Rails 中的扩展问题。

我只是好奇在 Rails 框架中处理 HTTP 请求的实际成本是多少。意思是，对于每个进来的请求，必须发生什么？有类解析吗？配置？建立数据库连接？

Answer 1

这实际上很大程度上取决于您使用的 Web 服务器以及您使用的配置，更不用说应用程序设计本身了。涉及的配置和设计问题包括：

• 无论您使用的是 fastcgi、老式 cgi 还是其他一些请求处理机制（影响您是否必须重新运行每个请求的所有应用程序初始化代码）
• 无论您是否使用 memcache（或替代缓存策略）（影响数据库请求的成本）
• 无论您是否使用其他负载平衡技术
• 您正在使用哪种会话持久性策略（如果需要）
• 无论您是否使用“开发”模式，这都会导致代码文件在更改时重新加载（我记得；也许只是每个请求）

与大多数 Web 应用程序框架一样，存在用于连接池、缓存和进程管理的解决方案。有很多方法可以管理数据库访问；通常，默认的不一定是最高性能，但调整该策略并不是火箭科学。

深入了解内部结构的人可能会说得更详细一些，但大多数应用程序要么使用 Apache 上的 FastCGI，要么使用对 Rails 更友好的备用 Web 服务器，这意味着每个进程只需要设置一次应用程序。

Answer 2

这是 Rails request 生命周期的一个很好的高级概述。完成此操作后，您可以选择特定部分进行分析和优化。

Answer 3

在 Phusion Passenger（又名 mod_rails）发布之前，部署的“标准”不是 FastCGI，而是使用以 Apache 和 mod_proxy（或 Nginx 等）为前端的 Mongrel 服务器集群。

“Rails 无法扩展”背后的主要问题是存在一些相当复杂的线程问题，这意味着在当前版本的 Ruby 和可用的服务机制中，Rails 不是线程安全的。这意味着运行 Rails 应用程序需要多个容器来支持高级别的并发请求。passenger 做了一些讨论，因为它在内部处理所有这些，并且也可以在改变内存处理方式的 Ruby（Ruby 企业版）的自定义构建上运行。

最重要的是，即将到来的 Ruby 和 Rails 版本都直接解决了线程问题，应该一劳永逸地结束这个论点。

就我而言，整个说法都是非常虚假的。“规模”是一个架构问题。