Rails請求初始化

Question

我們都聽到很多關於在Rails中擴展問題的信息。

我只是好奇在Rails框架中處理HTTP請求的實際成本是多少。意思是，每一個請求都會發生什麼？是否有類解析？組態？數據庫連接建立？

Answer 1

這實際上取決於您正在使用的Web服務器以及您正在使用的配置，更不用說應用程序設計本身。參與配置和設計問題包括：

• 無論你是使用FastCGI，老派的CGI，或其他一些請求處理機制（影響你是否正在將不得不重新運行所有的每個請求的應用程序初始化代碼或者沒有）
• 無論您使用的內存緩存（或備用的緩存策略）否（無論您使用額外的負載平衡技術或不
• 哪個會話持久性策略，你會影響數據庫請求的成本）
• '正在使用（如果需要）
• Wheth呃你是否使用「開發」模式，這會導致代碼文件在被更改時重新加載（我記得;也許它只是每個請求）

像大多數web應用程序框架一樣，有連接池，緩存和進程管理的解決方案。有很多方法來管理數據庫訪問;通常情況下，默認值不一定是最高性能，但調整該策略並非火箭科學。

深入挖掘內部的人可能會說出更令人痛苦的細節，但大多數應用程序在Apache上使用FastCGI或使用另一種更友好的軌道式Web服務器，這意味着每個進程只安裝一次應用程序。

Answer 2

在發佈Phusion Passenger（又名mod_rails）之前，部署的「標準」不是FastCGI，而是使用Apache和mod_proxy（或Nginx等）前端的Mongrel服務器羣集。

「Rails沒有擴展」背後的主要問題是事實上，有一些非常複雜的線程問題，這意味着當前版本的Ruby和可用的服務機制，Rails沒有線程安全。這意味着需要多個容器才能運行Rails應用程序來支持高級別的併發請求。 Passenger在內部處理所有這些問題時會做出一些嘗試，並且還可以在改變處理內存方式的Ruby（Ruby Enterprise Edition）自定義版本上運行。除此之外，Ruby和Rails的即將發佈的版本都直接解決了線程問題，應該一勞永逸地解決這個問題。

就我而言，整個索賠是非常虛假的。 「規模」是一個建築問題。

Answer 3

這是一個很好的高級別overview of the lifecycle of a Rails request。通過這個過程後，您可以選擇特定的部分進行配置和優化。