只是想獲得人們對使用Unicorn和Thin作爲Rails服務器的意見。我在網上找到的大多數文章/基準看起來都很不完整，所以最好有一個集中的地方來討論它。Heroku上的瘦身與獨角獸
Unicron是一個多進程服務器，thin是基於事件的/非阻塞服務器。基於事件的服務器非常好...如果你的代碼是異步/非阻塞的 - 香草欄被阻塞。所以除非你使用非阻塞的rails庫，否則我真的沒有看到使用Thin的好處。更糟糕的是，在非阻塞服務器中，如果你的I/O循環阻塞了，你將阻塞整個循環，直到阻塞調用返回後才能處理更多的請求。阻止圖書館將減緩減少！
爲什麼Heroku選擇Thin作爲他們的默認服務器（雪松）？他們是聰明的人，所以我相信他們有一個理由。
貝婁是一個鏈接，建議用4個獨角獸工人代替瘦 - 這對我來說非常合理。 4 Unicron workers on Heroku
薄易於配置 - 不是最佳的，但它只是在Heroku環境中工作。
獨角獸可以更有效率，但它需要進行配置：有多少工人？預加載應用程序？你選什麼？
我已經發布了Unicorn Heroku應用程序，其工作人員設置爲3,5和8--只是基於每個應用程序的大小 - 多少代碼，使用了多少內存以及您獲取的所有流量都選擇了這個數字，並且您需要隨時監控以確保您獲得了正確的號碼，並且您的應用沒有用完內存。
預緊假 - 這會讓你的應用程序啓動速度較慢，但是當獨角獸重新啓動工人，這與網絡連接（內存緩存，Postgres的，蒙戈等）
預緊真正的「安全」 - 這是更好的，但您需要在前後叉代碼中正確處理服務器重新連接。
Thin沒有任何開箱即用的問題，但您只能獲得執行過程。
總結：開箱即用配置Unicorn非常適合所有人使用（或根本不需要），而Thin可以讓工作人員以更少的支持請求運行。
預加載設置只會影響部署的加載時間 - 所以它不是一個巨大的應對。還有什麼我應該留意的？ – EugeneMi
Preload false可以在應用程序部署過程中將您的應用程序推送超過Heroku排隊請求的30秒。我遇到過這種情況，必須切換回Preload true - 然後您必須知道處理重新連接，例如， ActiveRecord，Memcache，MongoDB，Redis，NewRelic等等 –
你知道是否有圍繞Unicorn修改全局變量的問題。我想知道不同的工作人員是否都在共享全局名稱空間，或者他們是否保留了自己的全局變量。謝謝！ –
Heroku不使用智能路由 - 無論dyno是否繁忙，它都會隨機分配作業給dynos。因此，如果您的dyno無法同時處理多個作業，即使您正在爲許多免費的其他dynos付費，您也會得到延遲（可能是大量延遲）。 「這是正確的 - 如果你的應用程序需要與智能路由器80個DYNOS，它需要4,000隨機路由器。」 http://news.rapgenius.com/James-somers-herokus-ugly-secret-lyrics
Heroku上說，他們在這方面的工作，以及他們的計劃是，使之更容易使用獨角獸。他們基本上說：「糟糕，我們沒有注意到這是幾年的問題......現在我們看，這對Thin來說絕對是一個問題......所以我想你需要使用不同的程序而不是我們一直在推動這一切。「 http://news.rapgenius.com/Jesper-joergensen-routing-performance-update-lyrics
從Heroku的官方解釋（上面第二個鏈接）： 「Rails的，其實還不可靠支持的併發請求處理這讓Rails開發者無法利用由雪松堆棧提供了額外的併發能力，除非他們轉移到像Puma或Unicorn這樣的併發Web服務器。
部署到Cedar with Thin的Rails應用程序可以相當快地結束請求排隊問題。由於Cedar路由器不再代表應用進行任何排隊，因此在dyno排隊的請求必須等到單個Rails進程在隊列中完成。許多客戶都遇到了這個問題，我們未能採取行動，併爲他們提供了一種更好的方法來在Cedar上部署Rails應用程序。「
另外值得關注的是，他們的性能工具（包括New Relic）尚未報告時間在測功機隊列中度過的。 http://news.rapgenius.com/Lemon-money-trees-rap-genius-response-to-heroku-lyrics
哎呀。
感謝您閱讀rapgenius的文章 - 非常令人失望地瞭解Heroku如此巨大的失敗和歪曲。猜測帶走的是：你最好把牛的Unicorn的多個進程併發到併發中，因爲Heroku的動態級併發是一個假設。 – Yarin
這是運行像Torquebox這樣的集羣應用服務器的地方，可以真正獲得一些好處。如果您的應用擁有高流量，請從Heroku下載並部署3個羣集的Torquebox應用服務器。 Web和後臺進程的智能負載平衡，滾動部署，集羣化memcached和排隊構建它。這是一個盒子裏的堆疊。 – brightball
最近（僅在幾個月前）的後面Phusion Passenger的鄉親Heroku的添加支持。當然，這是你應該嘗試看看是否符合您的需求的替代品。
I即使使用1臺動態測速儀，它的速度也很快，而響應時間的下降是顯而易見的。 簡單的Passenger Ruby Heroku Demo託管在github上。
主要的好處，在Heroku索賠乘客是：
通過Nginx的靜態資產加速 - 不要讓你的Ruby應用服務靜態資產，讓Nginx的爲你做它和卸載你的應用程序爲真正重要的任務。 Nginx會做得更好。
多個工作進程 - 而不是在測功機上運行只有一個工人，乘客的Phusion上運行一個單一的賽道多工作，因此需要利用它的資源發揮到極致，給你更高的性價比。這種方法類似於Unicorn的方法。但與Unicorn不同，Phusion Passenger可根據當前流量動態調整工作進程的數量，從而在不需要時釋放資源。
內存優化 - Phusion乘客使用內存比Thin和Unicorn少。它還支持寫入時複製虛擬內存和代碼預加載，從而使您的應用在Ruby 2.0上運行時使用更少的內存。
請求/響應緩衝 - 所包含的Nginx緩衝器的請求和響應，從而保護你對慢客戶端應用程序（移動網絡例如移動設備）和提高性能。
帶外垃圾收集 - Ruby的垃圾收集器速度很慢，但是爲什麼您的訪問者需要很長的響應時間呢？通過在正常的請求 - 響應循環之外運行垃圾回收來解決這個問題！ Unicorn首次推出的這個概念已經得到了改進：Phusion Passenger確保同時只有一個請求正在運行帶外垃圾收集，從而消除了Unicorn的帶外垃圾收集帶來的所有問題。
JRuby支持 - Unicorn比Thin更好的選擇，但它不支持JRuby。 Phusion Passenger的確如此。
希望這會有所幫助。
真的不能完全回答你的問題。有一件事我不會想到這一點，Unicorn非常適合在github上查看自述文件：https://github.com/defunkt/unicorn#readme –