16

Puma について、そしてそれが Unicorn よりもいかに速いかについて、多くの話があります。ただし、JRuby と Rubinius のインスタンスにより適しているとも述べています。

私の質問: Ruby 1.9.3 を使用した Rails 3.2 アプリはどうですか? ユニコーンかピューマか？

4

1 に答える 1

13

ユニコーンとピューマの素晴らしい記事があります

http://ylan.segal-family.com/blog/2013/05/20/unicorn-vs-puma-redux/

Unicorn は、フォークされたプロセスを使用して複数の着信要求を同時に処理する Rack HTTP サーバーです。

  1. プロセス管理: Unicorn は、壊れたアプリで死亡したワーカーを刈り取り、再起動します。複数のプロセスやポートを自分で管理する必要はありません。Unicorn は、バックエンドにスケーリングするために選択した任意の数のワーカー プロセスを生成および管理できます。
  2. ロード バランシングは、オペレーティング システム カーネルによって完全に行われます。ビジーなワーカー プロセスの背後でリクエストが山積みになることはありません。
  3. アプリケーションがスレッドセーフかどうかは気にせず、ワーカーはすべて独自の分離されたアドレス空間内で実行され、一度に 1 つのクライアントのみにサービスを提供して、最大限の堅牢性を実現します。
  4. Rackラッパーを介してRuby on RailsのRack以前のバージョンとともに、すべてのRackアプリケーションをサポートします。
  5. USR1 シグナルを介して、アプリケーション内のすべてのログ ファイルを再度開きます。これにより、際どくて遅い copytruncate メソッドの代わりに、rename を介して logrotate がアトミックかつ迅速にファイルをローテーションできます。Unicorn は、1 つの要求からの複数行のログ エントリがすべて同じファイル内にとどまるようにするための手順も実行します。
  6. 接続を失うことなく nginx スタイルのバイナリ アップグレード。クライアントをドロップすることなく、Unicorn、アプリケーション全体、ライブラリ、さらには Ruby インタープリターをアップグレードできます。
  7. fork されたプロセスを処理する際にアプリケーションに特別なニーズがある場合の before_fork および after_fork フック。「preload_app」ディレクティブが false (デフォルト) の場合、これらは必要ありません。
  8. コピー オン ライト対応のメモリ管理と併用してメモリを節約できます (「preload_app」を true に設定することにより)。
  9. UNIX ソケットを含む複数のインターフェイスでリッスンできる各ワーカー プロセスは、簡単にデバッグできるように、after_fork フックを介してプライベート ポートにバインドすることもできます。

  10. 構成のためのシンプルで簡単な Ruby DSL

    1. チャンクされた転送をオンザフライでデコードするため、アップロードの進行状況通知を実装できるだけでなく、HTTP 経由で任意のストリームベースのプロトコルをトンネリングできます。

Puma (いわゆるサーバー雑種の新しいバージョン) の場合

Puma は、Ruby Web アプリケーション用のシンプルで高速、高度な同時実行 HTTP 1.1 サーバーです。Rack をサポートする任意のアプリケーションで使用でき、Webrick および Mongrel の代替と見なされます。Rubinius の頼りになるサーバーとして設計されましたが、JRuby や MRI でもうまく機能します。Puma は、開発環境と本番環境の両方で使用することを目的としています。

Puma はスピードと並列性で人気

速度比較を見たい場合は、puma が最適です。

詳細については、http://puma.io/を参照してください。

ありがとう

于 2013-07-31T08:52:28.173 に答える