struts 1.xフォームのスコープは、なぜリクエストスコープが高速ですか？

Question

struts 1.x

セッションに強制されない限り、私は常にscope = "request"のstrutsフォームアクションマッピングを定義しています。例：

このアクションマッピングをリクエストスコープからセッションスコープに変換すると、ほとんどの場合パフォーマンスが低下します。セッションスコープのフォームBeanの余分なワークロードを引き起こすstrutsサーブレットに対する余分なメソッド呼び出しは何ですか？

Answer 1

requestスコープの場合、またはsessionスコープの場合、ActionFormの処理方法はまったく異なります。

リクエストスコープの場合、ユーザーがHTMLフォームを送信すると、StrutsはActionFormをインスタンス化し、リクエストパラメータをバインドしてから、ビューを消費するためにrequest.setAttribute(...)でリクエストスコープに配置します。要求が処理されると、要求のすべてのデータが現在有効範囲外になっているため、ActionFormが消えます（ガベージコレクションの対象）。新しいリクエストごとにActionFormが作成、使用、破棄されます。

セッションスコープの場合、ユーザーがフォームを送信すると、Strutsはセッション内でActionFormを見つけようとします。見つかった場合は、それを使用してリクエストパラメータをバインドします。 1つが見つからない場合は、1つを作成し、session.setAttribute(...)とセッションに入れます。要求が処理されると、ActionFormはセッション中に残り、それ以降の要求に対しては再利用されます。

上記はパフォーマンス上のオーバーヘッドにはなりません。

セッションとは、アプリケーションの各ユーザーのサーバー上のデータを意味します。このデータはメモリを意味します。ユーザーが多いほどメモリが増えます。通常、サーバは、メモリよりも多くのユーザデータが処理できる場合、このデータを永続ストレージに移動します。セッションデータは、不要になったときにディスク上でシリアル化され、再度必要なときにデシリアライズされます（データベースはデータの別のストレージタイプです）。

これはどういうことでしょう。メモリが不足しており、サーバーがディスクに格納/復元して、メモリアクセスよりも遅いIO操作を引き起こします。

指定されたスコープに応じてフォームを処理する方法は、赤いニシンかもしれません。最初にセッションを確認してください。