JSF がセッションをいっぱいにする問題が発生しています。先日システムクラッシュがありました。レビューのためにヒープを IBM に送信したところ、50M ものセッションがあったことがわかりました。彼らは、セッション内に JSF コンポーネントと非常に大きなものを見つけました。
それで、実行できるチューニングはありますか？設定項目は? または他の方向。
私たちのシステムは、プレゼンテーション層に JSF と Spring を使用して構築されており、バックエンドは EJB、Spring、および Hibernate であり、すべて WebSphere 6.1 で実行されています。
JSF は便利なテクノロジですが、使いこなすこともできます。
コンポーネントに大きな値を設定してビューステートのサイズを大きくしている、またはコンポーネントへの参照を他のセッション状態にリークしている (これは悪いことです) ようです。もう 1 つの潜在的な原因は、ビューが大きすぎることです (UI ツリーを簡単に作成できると、どこにでもデータ テーブルがある非常に大きなコントロール グラフが作成されることがわかりました)。IBM がリッチ テキストとスプレッドシート コントロールを提供していることは知っていますが、これらの使用が状態サイズに与える影響についてコメントすることはできません。
簡単に達成できる成果は、faces-config.xmlでセッション スコープ用に構成されたマネージド Bean を確認することです。
JSF は、リクエスト間で次の 2 つのことを保存します。
データ テーブルの子など、一部のコントロールは複数の状態 (行ごとに 1 つ) を持つことができるため、これらは分離されています。状態は、フォームの非表示フィールド (暗号化されていない場合、大きなセキュリティ上の問題になる可能性があります) またはセッションに保存できます。同じセッションを共有する複数のブラウザ ウィンドウに対応するため (および、一部の実装では戻るボタンのサポート)、複数のビューが保存されます。
ほとんどの IDE ビルド JSF アプリにはバッキング Bean があります。セッション Bean スコープを介して、必要以上に長く状態を保持し、セッションに負担をかける可能性があります。ページごとに 1 つのバッキング Bean が存在する傾向があるため、ページ数が多いほど問題は大きくなります。faces-config.xmlをチェックして、これが潜在的な問題の原因であるかどうかを確認してください。
他にできることは、web.xmlでHttpSessionAttributeListenerを構成することです。スタック トレースを取得して、アプリの問題領域を特定できます。
これは、JSF と過剰なオブジェクト作成のために停止したと聞いた 2 番目のシステムです。もう 1 つは、バックエンドで Spring と Hibernate も使用していました。OptimizeIt を使用したプロファイリングでは、バックエンドの応答がすべての要求に対してミリ秒単位であることが示されましたが、30 秒から数分と非常に長い時間がかかったため、ストップウォッチを使用してブラウザーのレンダリングの時間を計ることができました。クライアントが消費するメモリはばかげていました。
私はオブザーバーにすぎず、そのプロジェクト チームのメンバーではありませんでした。問題が修正されたかどうか、また修正された場合は、どのような解決策があったかを尋ねなければなりません。
しかし、もし 2 つの点が傾向を示しているとすれば、JSF には致命的な欠陥がある可能性があると言えます。個人的には、完全に避けています。
Spring Web フロントエンドを試してみて、それが役立つかどうかを確認してみませんか? Spring のイディオムに従えば、JSF を JSTL ベースの JSP と Spring コントローラーに置き換えるのは比較的簡単なことです。
私は JSF プロジェクトに取り組んでいましたが、複数の JSF h:form 要素を追加するバグがあることがわかりました。ビューステート全体のコピーがすべてのフォームに含まれます。1 ページあたり 1 フォームに削減すると、ページが ~2M から ~300K に削減されました。
少し古いトピックですが、最近これに出くわしました。多くの場合、[表示]と[表示状態]は保存され（前述のとおり）、セッションがいっぱいになり、[戻る]ボタンが機能するようになります。設定する必要のあるデプロイメント記述子（web.xml）でこれをソートするためのパラメーターがあります。
MyFacesやJSFRIを使用する場合など、特定のライブラリの複数のインスタンスで複数のパラメータ設定が必要になる場合があります。デフォルトでは、かなり高い値に設定できます（それぞれ、20と16だと思います）。これは、セッション（の一部？）に必要なスペースの20倍を使用できることを意味します。
セッション スコープとして多数のバッキング Bean で問題が発生している可能性があります。
MyFaces Orchestraを調べてみてください。これは会話スコープを提供するライブラリであるため、ユーザーが特定の Bean セットを終了すると、セッションから削除されます。
Spring WebFlow にも同様の機能があることは理解していますが、実際には調べていません。
実稼働環境向けの JSF チューニングのヒント:
- 画像、CSS、および JavaScript リソースの使用は、(img,link,script)サーバー側ではなく標準の HTML タグによって行う必要が#{request.contextPath}あります。相対パスの問題を回避するために、必ず URL の前に設定してください。-を使用し
てページの静的セクションをキャッシュします-変数を -1 に
設定します - Production に
設定し
ます - コード フィルターがある場合は確認します (menu,header,footer)omnifaces cacherefresh-periodproject-stage
また、DZone の私の記事「Java Server Faces in Real-Life Applications」もチェックしてください。開発環境、テスト環境、および本番環境における JSF の全体像がわかります。
セッション永続性をデータベースに構成すると、使用頻度の低いアルゴリズムを使用して、使用頻度の低いセッションをメモリからプッシュします。（適切に構成されている場合）高性能であり、具体的かつ迅速に役立ちます。
JSF は、豊富なコンポーネント ベースのアーキテクチャ (ビューの状態を維持する必要がある) をサポートするためにビューをセッションに保存し、適切に使用しないとヒープをいっぱいにする可能性があります。大きなワークフローがない場合は、常にセッションあたりのビュー数を少なくしてください。また、backingbean をセッション中に保持することはできる限り避けてください。カスタム タグを使用して、次の要求サイクルのためだけにデータ オブジェクトを作成します。JSF で Spring Web Flow を使用することもできます。これにより、アプリケーションに長いワークフローがある場合にビュー スコープとフロー スコープが導入され、セッションで構成されたビューの数が減ります。JSF はリッチなユーザー インターフェイスを簡単に作成するために使用でき、デスクトップ アプリケーションに似た Web アプリケーションを構築するのに役立ちます。特定のヒープを JSF フレームワークに割り当てて、その作業を行います。ただし、アプリケーション側でメモリを効率的に使用し、メモリ リークがないことを確認してください。すべてのメモリ リークは、開発中に調査して修正する必要があります。プロファイラーを使用して、アプリケーションに存在するメモリ リークとパフォーマンスのボトルネックを見つけます。
マット。
MyFaces < 1.1.6 を使用している場合、セッション内の古いシリアル化されたビューを効果的にキャッシュする方法で大量のメモリ リークが発生し、ガベージ コレクションが可能になるため解放されません。これには深刻な問題があり、50Mb のセッションもありました。MyFaces の迅速なアップグレードにより、問題は問題なく修正されました。