我们都听到了很多有关Rails中伸缩问题的信息。

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

解决方案

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

• 无论我们使用的是fastcgi，老式的cgi还是其他请求处理机制(都会影响我们是否必须针对每个请求重新运行所有应用初始化代码)
• 是否使用内存缓存(或者备用缓存策略)(影响数据库请求的成本)
• 是否使用其他负载平衡技术
• 我们正在使用哪种会话持久性策略(如果需要)
• 无论我们是否使用"开发"模式，都会导致代码文件在更改时重新加载(我记得；也许只是按请求)

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

深入了解内部原理的人可能会讲得更详细一些，但是大多数应用程序都使用Apache上的FastCGI或者其他对Rails友好的替代Web服务器，这意味着每个进程只需要设置一次应用程序。

在发布Phusion Passenger(aka mod_rails)之前，用于部署的"标准"还不是FastCGI，而是使用由Apache和mod_proxy(或者Nginx等)开头的Mongrel服务器集群。

" Rails无法扩展"背后的主要问题是，存在一些相当复杂的线程问题，这意味着在当前版本的Ruby和可用的服务机制中，Rails并不是线程安全的。这意味着需要多个容器来运行Rails应用程序以支持高级别的并发请求。乘客可以从内部处理所有这些问题，并可以在定制的Ruby(Ruby Enterprise Edition)构建版本上运行，该版本可以更改内存的处理方式。

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

就我而言，整个索赔都是虚假的。 "规模"是一个架构问题。

这是Rails请求生命周期的高级概述。完成此操作后，我们可以选择特定部分以进行概要分析和优化。