GlassfishでSSLを介して実行され、Liferayを使用するポータルがあります。前回、Glassfishが「ストール」したリリース情報に同時にアクセスするために約200人を招待するメールを送信しました。
サーバーから、システムリソースに問題がないことがわかりました。-Glassfishは最大8GBを使用できますが、5 GBを使用していました-サーバーには4つのCPUがあり、全体の使用率は約30％でした-Glassfishは最大400のHTTPスレッドで構成されています。
サーバーがユーザーに応答していないことを検出するとすぐに、何が起こっているのかを理解するためにプロファイラーを起動しました。
スレッドの概要には、ブロックされたスレッドが多すぎます。
スタックから、太陽、グリズリー、カタリナのクラス以外のコードを確認することはできません。
このような問題を修正したいのですが、今のところ、SSLを無効にするなど、一部のコンポーネントを置き換える必要があるコードで作業する必要があるかどうかを判断できます。
どんな考えでも大歓迎です。
ありがとう。
スレッドダンプは、プロファイラーよりも簡単で邪魔にならない可能性があります。これにより、実際の実行中のシステムでスレッドがブロックされている場所が示されている可能性があります。
ブロッキングが発生した場所を把握する必要があります。それはLiferayのコードにあるのか、それとも自分のコードにあるのか。あなたはページに何を持っていましたか、テーマはどのように行われますか？また、Liferayの非常に古いバージョンを実行していることに注意してください。CEを実行している場合、これは数年間メンテナンスされていません（Enterprise Editionは引き続きサポートされていますが、これについては言及していませんが、オッズCommunity Edition（CE）を実行していますか）
さらに、説明したような状況（同時に大量の人を送信する）が発生した場合は、システムがどのように動作するかを確認するために、人工的な負荷を使用してシステムの負荷テストを行うことをお勧めします。また、ランディングページをバッファリングすることもできます（これは、200人のユーザーが多いということではありませんが、そのようなアクティビティについては、システムがそれを処理できることを知りたいと思うでしょう）
反対のことを証明するまでは、ページ上に、ボトルネックと発見したブロッキングの原因となるカスタムコンポーネント（ポートレットまたはテーマのいずれか）があると思います。