Lift ウェブフレームワークが高いパフォーマンスとスケーラビリティを備えている技術的な理由を知りたいですか? アクター ライブラリを持つ scala を使用していることは知っていますが、インストール手順によると、デフォルトの構成は jetty です。アクター ライブラリを使用してスケーリングするのでしょうか。
今では、箱から出してすぐに構築されたスケーラビリティです。サーバーとノードを追加するだけで、自動的にスケーリングされます。サポートするサーバーとの 500000 以上の同時接続を処理できますか。
私はエンタープライズ レベルの Web サービス フレームワークを作成しようとしています。これは既存のものよりも優れており、スケーリング、構成、および保守が容易です。私のスケーリングの定義は、サーバーを追加することであり、余分な負荷に対応できるはずです。
ありがとう
スケーラビリティに対する Lift のアプローチは、単一のマシン内にあります。マシン間のスケーリングは、より大規模で難しいトピックです。簡単に言えば、Scala と Lift は、水平方向のスケーリングを助けたり妨げたりすることはありません。
単一のマシン内のアクターに関する限り、Lift はより優れたスケーラビリティを実現します。これは、単一のインスタンスが他のほとんどのサーバーよりも多くの同時要求を処理できるためです。説明するには、まず、従来のリクエストごとのスレッド処理モデルの欠点を指摘する必要があります。我慢してください、これにはいくつかの説明が必要です。
一般的なフレームワークは、スレッドを使用してページ要求を処理します。クライアントが接続すると、フレームワークはプールからスレッドを割り当てます。次に、そのスレッドは次の 3 つのことを行います。ソケットから要求を読み取ります。何らかの計算を行います (データベースへの I/O を伴う可能性があります)。そして、ソケットで応答を送信します。ほとんどすべてのステップで、スレッドはしばらくの間ブロックされます。リクエストを読み取るとき、ネットワークを待っている間にブロックすることができます。計算を実行すると、ディスクまたはネットワーク I/O でブロックされる可能性があります。データベースの待機中にブロックすることもできます。最後に、応答の送信中に、クライアントがデータをゆっくりと受信し、TCP ウィンドウがいっぱいになると、ブロックされる可能性があります。全体として、スレッドはブロックされた時間の 30 ～ 90% を費やす可能性があります。ただし、その 1 つの要求に 100% の時間が費やされます。
JVM は、実際に速度が低下する前に、非常に多くのスレッドしかサポートできません。スレッドのスケジューリング、共有メモリ エンティティ (接続プールやモニターなど) の競合、およびネイティブ OS の制限はすべて、JVM が作成できるスレッドの数に制限を課します。
JVM のスレッドの最大数が制限されていて、スレッドの数によってサーバーが処理できる同時要求の数が決まる場合、同時要求の数はスレッドの数によって決まります。
(たとえば、GC スラッシングなど、より低い制限を課す可能性のある問題は他にもあります。スレッドは基本的な制限要因ですが、唯一の要因ではありません!)
Lift はスレッドをリクエストから切り離します。Lift では、リクエストはスレッドを拘束しません。むしろ、スレッドはアクション (リクエストの読み取りなど) を実行してから、アクターにメッセージを送信します。アクターは「軽量」スレッドを介してスケジュールされるため、ストーリーの重要な部分です。スレッドのプールは、アクター内でメッセージを処理するために使用されます。アクター内で操作をブロックしないようにすることが重要です。これにより、これらのスレッドはすぐにプールに戻されます。(このプールはアプリケーションから見えないことに注意してください。これは Scala のアクターのサポートの一部です。) たとえば、現在データベースまたはディスク I/O でブロックされている要求は、要求処理スレッドを占有したままにしません。要求処理スレッドは、ほとんどすぐに使用可能になり、より多くの接続を受信できます。
リクエストをスレッドから切り離すこの方法により、Lift サーバーは、リクエストごとにスレッドを実行するサーバーよりも多くの同時リクエストを処理できます。(Grizzly ライブラリーがアクターなしで同様のアプローチをサポートしていることも指摘しておきたいと思います。) 同時リクエストが多いということは、単一の Lift サーバーが通常の Java EE サーバーよりも多くのユーザーをサポートできることを意味します。
mtnyguardで
「ScalaとLiftは、水平方向のスケーリングを支援または妨害するために何もしません」
正しくありません。リフトは非常にステートフルなフレームワークです。たとえば、ユーザーがフォームをリクエストした場合、フォーム処理アクションはサーバー状態で保存されるため、ユーザーはフォームが送信されたのと同じマシンにのみリクエストを投稿できます。
そして、これは実際には、ある意味でスケーラビリティを妨げるものです。これは、この動作がシェアードナッシングアーキテクチャと矛盾しているためです。
リフトのパフォーマンスが高いことは間違いありませんが、パフォーマンスとスケーラビリティは2つの異なるものです。したがって、リフトを使用して水平方向にスケーリングする場合は、ロードバランサーでスティッキーセッションを定義する必要があります。これにより、セッション中にユーザーが同じマシンにリダイレクトされます。
Jetty がエントリ ポイントかもしれませんが、最終的にはアクターがリクエストにサービスを提供することになります。非常にスケーラブルなサービスを作成する方法を確認するために、Twitter 風の例である「スキッター」を参照することをお勧めします。IIRC、これは twitter の人々に注目を集めさせたものの 1 つです。
@dre の返信は本当に気に入っています。リフトのステートフルネスが水平方向のスケーラビリティの潜在的な問題であると正しく述べているからです。
問題 - 全体を再度説明する代わりに、この投稿の (コンテンツではなく) ディスカッションを確認してください。http://javasmith.blogspot.com/2010/02/automagically-cluster-web-sessions-in.html
解決策は、@dreがフロントのロードバランサーでスティッキーセッション構成を述べ、インスタンスを追加することです。しかし、lift でのリクエスト処理はスレッド + アクターの組み合わせで行われるため、1 つのインスタンスが通常のフレームワークよりも多くのリクエストを処理することが期待できます。これにより、他のフレームワークでスティッキー セッションを使用するよりも有利になります。つまり、より多くを処理する個々のインスタンスの容量は、スケーリングに役立つ場合があります