擴大規模紅寶石，ActiveRecord的，MySQL的應用

Question

我有一個應用程序...

的應用程序做一個金融產品市場的比較 - 對於一個給定的報價請求時，它與其他幾個網站爲他們的報價。然後它給用戶結果 - 幾個引用的細節。

爲了管理這些請求他們得到保存到MySQL，然後我的應用程序踢，拿起待定報價和農場這些出線程（所有相同的Linux盒）來處理每個站點查找。

我使用JRuby因爲我有線程/ DB相關問題。使用Java線程池來控制線程數。使用當前的硬件/ VPS - 它可以處理大約200個線程。許多限制似乎與每個線程都抓住他們自己的MySQL連接有關 - 抓住報價細節並挽回結果。我們想要處理更多的併發線程，並尋找擴展方法。

想知道哪個方向走......

1. 更大的硬件...
2. 更多的計算機，並使用某種排隊 機制（具有優先級）的跨機器共享負載 - 所以螺紋別碰分貝，通過 所有的細節/響應去排隊 - 這樣的DB命中是少了，但那麼也許我只是推 問題到隊列中。使用類似 MongoDB的隊列的思考，但開放的建議 - 這是很容易 使用用Ruby :)
3. 某種類型的遠程/ RPC機制，如DRB - 理論上這似乎是一個不錯的選擇，但不用它做任何事情 但還不知道它會使事情變得複雜。
4. 東西 別的......？

從這個鏈接Reasons for NOT scaling-up vs. -out? - 這似乎是這個問題適合運行更多的機器來解決它。

因此，任何想法上的路要走......

乾杯， 克里斯

Answer 1

我通常的做法是這樣的問題是非常密切地關注到你正在做的數據庫查詢和調整他們積極。檢索只有你需要什麼，跳過沒有明確使用的列，並且非常小心急於加載你不需要的東西。

您經常會發現通過添加索引或戰略性地減少數據庫中的某些屬性以避免難看且耗時的操作，您可以獲得顯着的速度提升。

此外，想想緩存：最快的數據庫調用是從來沒有作出一個。使用Memcached之類的功能並不難保存適度耗時的記錄檢索結果，如果仔細完成，甚至可以很容易地失效並過期，只要您通過幾種方法引導更新即可。

對於調度工，一個簡單的先入先出隊列可以在Redis的實現從MySQL本身卸載大量的處理開銷。如果你遵循一個例子，這通常很容易添加。

像Memcached這樣的緩存可以處理極高的流量，所以只要有可能，緩存就可以避免每次最後碰到數據庫。

如果您已經用盡了這些選項，那麼現在是更多前端服務器和更多數據庫容量的時候了，但只有這樣。

Answer 2

排隊是最容易實現的。使用類似這樣的東西：http://beanstalkd.github.com/beaneater/

基本上，你可以在async.之前預先安排好你的方法，然後將它們放入隊列並執行它們。他們排隊和工人可以是同一臺服務器或不同的服務器。