Erlang（或elixir）性能（每秒請求數）對jruby緩慢？

Question

作為一個rubyist，我決定采用erlang來獲得高性能，可靠的后端。 設置非常簡單：獲取發布請求，將內容寫入redis，返回統計信息。 所有的json。 這也是為什么我非常關心每秒的請求。

選擇的工具： webmachine ， 瞬間對JSON編碼/解碼， poolboy用於連接池，並且eredis為redis的通信。

機器使用：macbook pro，i5 2.4Ghz，8GB內存。

我的erlang每秒大約有5000個請求，而jruby / torqbox大約有12,0000個請求。 （ 在這里查看完整的ruby性能測試設置 ）

我意識到我可以在erlang中使用ets來節省時間，並且在響應之后留下用於“后台處理”的redis，但這將沒有什么影響。 甚至是對'你好世界'背后的二郎腿的簡單測試。

有什么建議？ 我做錯了嗎？

Answer 1

• Webmachine - 我不知道。 對於我的味道來說它是非常重的，我不使用它。
• jiffy - 不錯的選擇。 非常快，我經常使用它。
• poolboy - 我沒有聽說過，我在Erlang身邊已經好幾年了。 我肯定會將牛仔用於任何我期望的高性能或偏航以獲得更堅固但仍然表現良好的東西。 對於你的基准是牛仔正確的選擇，它是最佳的性能。
• eredis - 我不知道它有多成熟以及如何有效。 ets更適合基准測試。 對於你的macbook測試，無所謂，但對於大型服務器（數十個CPU），我會檢查ti是不是瓶頸和分區表。
• 最重要的是檢查您的VM參數。 對於這種負載，至少你應該有+K true +A 100 。

與我的經驗相比，你對Erlang的結果似乎太低了。 你應該得到幾乎十倍的大。 您的有效負載生成工具也可能存在問題。

而且最重要的是，這不僅可以被認為是Erlang世界的微觀基准，也可能是納米或atto基准。 真正的力量將揭示你何時會嘗試更艱難，更復雜的事情。 並發請求應以非常復雜的方式相互影響的事情，您必須處理最終的一致性並實現更具可伸縮性，並且需要使用異步進程間通信。

Answer 2

我的2美分。 你有錯誤的結局。 您正在測試JVM針對JVM優化的某種機器進行優化的問題。

你真的不會看到Erlang / OTP對mac book pro上可用內核數量的優勢。 這只是我的粗略猜測，但我會驚訝地看到Erlang在不到8核心服務器上擊敗了JVM。 在當前硬件上盡可能快地制作JVM需要大量的人/小時。

編寫線程安全的I / O代碼相當簡單，當您處理數十到數百個線程中的內存訪問時，會出現真正的問題。

在Erlang / Elixir中編寫的目標是當前16或32核的高端服務器，並且在不久的將來可能會擴展得更高。

Answer 3

僅供參考：“+ A 100”對網絡沒有幫助，只適用於文件IO。 如果你真的想要快速的網絡服務器，請看看github.com/knutin/elli，它將為你提供80 kprs的硬件，牛仔將給你30 krps。 另一方面，elli是許多人因不遵守OTP原則而責備的事情。

如果您可以放置​​一些負載均衡器來清理請求，那么jiffy是一個不錯的選擇，因為jiffy會在您的代碼中引入段錯誤 - 請查看問題列表。

無論如何，如果你需要的只是快速的GET - >解碼json - > store - > REPLY工作負載，那么你不想選擇erlang。