Erlang（またはelixir）のパフォーマンス（1秒あたりのリクエスト数）はjrubyと比べて遅いですか？
ルビイストである私は、高性能で信頼性の高いバックエンドのためにerlangを採用することにしました。セットアップは非常に簡単です。POSTリクエストを取得し、redisにデータを書き込み、統計を返します。すべてのjson。これが、私が1秒あたりのリクエストを非常に気にする理由でもあります。
選択するツール： webmachine 、 Jiffy jsonエンコーディング/デコーディング、 poolboy 接続プール、 eredis redisコミュニケーション。
使用したマシン：macbook pro、i5 2.4Ghz、8GBメモリ。
私のerlangは1秒あたり約5000のリクエストを受け取り、jruby/ torqbox は約12,0000を受け取りました。 （ 完全なRubyパフォーマンステストのセットアップ をここで探してください）
Erlangでetsを使用して時間を節約し、応答後に「バックグラウンド処理」のredisを書き込むことができると思いますが、これによる影響はほとんどありません。背後にある「helloworld」erlangレッグの簡単なテストですら。
助言がありますか？私はそれを間違っていますか？
- Webmachine-わかりません。味はかなり重いので使っていません。
- ジフィー-良い選択。かなり速く、私はそれをよく使います。
- poolboy-私はそれについて聞いていません、そして私は数年間Erlangの周りにいます。私は間違いなく cowboy を使用して、高性能を期待するもの、または yaws を使用して、より堅実でありながら良好なパフォーマンスを発揮します。あなたのベンチマークはカウボーイの正しい選択であり、それはパフォーマンスの面で最高です。
- eredis-どれほど成熟していて、どのように効率的かはわかりません。 etsはベンチマークに適しています。あなたのmacbookテストではそれは問題ではありませんが、大きなサーバー（数十のCPU）ではtiがボトルネックやパーティションテーブルではないかどうかをチェックします。
- 最も重要なのは、VMパラメータを確認することです。少なくとも、この種の負荷には
+K true +A 100が必要です。
Erlangの結果は、私の経験と比較して単純に低すぎるようです。ほぼ10倍大きくなるはずです。ペイロード生成ツールにも問題がある可能性があります。
そして最も重要なことは、これはErlangワールドのマイクロベンチマークであるだけでなく、nanoまたはattoベンチマークと見なすことができるということです。あなたがもっともっともっともっともっと複雑なことをしようとすると、本当の強さが明らかになります。同時リクエストが非常に複雑な方法で相互に影響を及ぼし、結果整合性に対処し、それをはるかにスケーラブルに実装する必要があり、非同期プロセス間通信を使用する必要がある場合。
私の2セント。スティックの端が間違っています。 JVMが動作するように最適化されている種類のマシンで、JVMが最適化されている問題をテストしています。
Mac BookProで利用可能なコアの数に関するErlang/OTPの利点を実際に目にすることはありません。これは私の大まかな推測ですが、Erlangが8コアサーバー未満でJVMを打ち負かしているのを見て驚かれることでしょう。現在のハードウェアでJVMを可能な限り高速化するために、膨大な数の工数が費やされてきました。
スレッドセーフなI/Oコードの記述はかなり簡単です。実際の問題は、数十から数百のスレッド間のメモリアクセスを処理するときに発生します。
Erlang/Elixirでの書き込みは、16コアまたは32コアの現在のハイエンドサーバーを目指しており、近い将来、はるかに高度に拡張できる可能性があります。
参考：「+ A100」はネットワーキングには役立ちません。ファイルIO専用です。高速なWebサーバーが本当に必要な場合は、github.com/knutin/elliを参照してください。ハードウェア上で、カウボーイが30krpsを提供する80kprsを提供します。一方、elliは、多くの人がOTPの原則に従わなかったと非難しているものです。
Jiffyはコードにセグメンテーション違反を導入するため、リクエストをサニタイズするためにロードバランサーを配置できる場合は、Jiffyが最適です。問題リストをご覧ください。
とにかく、erlangは、必要なのが本当に高速なGET-> decode json-> store-> REPLYワークロードだけである場合、選択したいものではありません。