18

rubyist として、高性能で信頼性の高いバックエンドを得るために erlang を採用することにしました。設定は非常に簡単です: post リクエストを取得し、redis に書き込み、統計を返します。すべてのjson. これが、私が 1 秒あたりのリクエスト数を重視する理由でもあります。

最適なツール: webmachine、json エンコード/デコード用のjiffy、接続プール用の poolboy、およびredis通信用の erdis。

使用マシン：macbook pro、i5 2.4Ghz、メモリ8GB。

私の erlang は 1 秒あたり約 5000 のリクエストを受け取り、jruby/ torqboxは約 12,000 のリクエストを受け取りました。(完全な Ruby パフォーマンス テストのセットアップについては、こちらを参照してください)

時間を節約するために erlang で ets を使用し、応答後に「バックグラウンド処理」を書き込むために redis を残すことができることを認識していますが、これはほとんど影響しません。'hello world' erlang の足の後ろの簡単なテストでさえ。

助言がありますか？私はそれを間違っていますか？

4

3 に答える 3

19
  • Webmachine - わかりません。私の好みではかなり重量があり、使用していません。
  • jiffy - 良い選択です。かなり速く、私はそれをたくさん使います。
  • poolboy - 私はそれについて聞いたことがありません。私は数年間 Erlang を使用しています。私は間違いなく、高性能を期待するものにはカウボーイを使用し、より堅実でありながら優れたパフォーマンスを発揮するためにヨーを使用します. あなたのベンチマークはカウボーイの正しい選択であり、パフォーマンスに関しては最高です。
  • edis - どの程度成熟しており、どの程度効率的かはわかりません。ets はベンチマークに適しています。Macbook のテストでは問題ではありませんが、大規模なサーバー (数十の CPU) では、ti がボトルネックやパーティション テーブルでないかどうかを確認します。
  • 最も重要なことは、VM パラメータを確認することです。少なくとも+K true +A 100、この種の負荷には必要です。

Erlang に対するあなたの結果は、私の経験に比べて低すぎるように思えます。ほぼ10倍大きくなるはずです。ペイロード生成ツールにも問題がある可能性があります。

そして最も重要なことは、これは Erlang の世界のマイクロ ベンチマークだけでなく、nano または atto ベンチマークと見なすことができることです。本当の強さは、より困難で複雑なことに挑戦したときに明らかになります。同時リクエストが非常に複雑な方法で互いに影響を与える必要があり、結果整合性に対処し、よりスケーラブルに実装する必要があり、非同期プロセス間通信を使用する必要があるもの。

于 2014-08-14T09:40:25.030 に答える
7

私の2セント。スティックの端が間違っています。JVM が動作するように最適化されている種類のマシンで、JVM が最適化されている問題をテストしています。

Mac book pro で利用可能なコアの数に関して、Erlang/OTP の利点を実際に目にすることはありません。これは私の大まかな推測にすぎませんが、Erlang が 8 コア未満のサーバーで JVM を打ち負かすのを見ると驚かれることでしょう。現在のハードウェアで JVM を可能な限り高速にするために、膨大な数の工数/時間が費やされてきました。

スレッド セーフな I/O コードを記述するのは非常に簡単ですが、実際の問題は、数十から数百のスレッド間でメモリ アクセスを処理するときに発生します。

Erlang/Elixir での記述は、近い将来さらに拡張する可能性のある 16 または 32 コアの現在のハイエンド サーバーを目指しています。

于 2014-09-02T03:01:48.190 に答える
5

参考までに:「+A 100」はネットワークには役に立たず、ファイル IO のみに使用されます。本当に高速な Web サーバーが必要な場合は、github.com/knutin/elli を参照してください。カウボーイが 30 krps を提供するハードウェアで 80 kprs を提供します。一方、elli は、OTP の原則に従わないことで多くの人が非難しているものです。

jiffy はコードに segfaults を導入するため、ロード バランサーを配置してリクエストをサニタイズできる場合に適しています。

とにかく、erlang は、本当に高速な GET -> json のデコード -> store -> REPLY ワークロードだけが必要な場合に選択する必要はありません。

于 2014-08-23T00:02:59.137 に答える