私は最近scalaを学び、Liftフレームワークの作業/学習を始めようとしています。機能を調べてフレームワークを使い始めると、リバースajaxやcometなどのフレームワークの驚くべき機能をいくつか見てきました。私の経験の初期には、スケーリングされなかったリバースajaxで本当に悪い経験をしました。開発にリフトフレームワークを選択した場合、これが理由になります。ここでの私の質問は、テクノロジーと製品がどれほど成熟しているか、Tomcatのリフトを使用してどれだけスケーラブルかということです。この目的に適したサーブレット仕様3.0と比較して、サーブレット仕様3.0を待つか、リフトの使用を開始しますか?
1 に答える
リバースAJAXはCometです。それらは同じものの2つの異なる名前です。あなたの質問の根源については...
LiftのCometサポートのスケーラビリティは、サーブレットコンテナに大きく依存します。継続をネイティブにサポートするコンテナが本当に必要です。突堤は私がよく知っているものですが、他にもあると確信しています。コンテナレベルで継続をサポートすることで、Cometのスケーラビリティの問題のほとんどが原因であるクライアントごとのスレッドのロックを回避できます。
スケーラビリティの他の領域では、Lift'sCometActor
は、アクティブなロングポーリングを持つ単一のクライアントに関する一般的な抽象化です。この抽象化はアクターであるため、既存のアクターフレームワーク(Lift1.0.xの場合はScalastdlib、2.0の場合はLiftアクター)内で処理できます。これもスレッドスケーリングの問題を回避し、保留中の更新が整然とキューに入れられるようにします。
つまり、LiftのCometサポートは、Cometとほぼ同じくらいスケーラブルです。もちろん、この手法に関連する固有のオーバーヘッドがあります。クライアントごとに少なくとも1つのソケットをコミットすることを回避することはできません。ただし、Liftは(継続が有効なコンテナーとともに)、箱から出してすぐに不要なオーバーヘッドを軽減することができます。