0

WebアプリをJSFマネージドBeanからCDIマネージドBeanに移行したばかりですが、「OpenWebBeans」について聞いた素晴らしいことから、TomcatまたはTomEEPlusを選択するコンテナーにしたいと考えていました。TomEE 1.5+ / CDI管理対象BeanWebアプリケーションをデプロイ、構成、およびテストした後、フルページ更新はGlassfish 3.1.2.2 / MyFaces 2.1.9/JSF管理対象Beanよりもはるかに低速です。

Glassfish 3.1.2.2 / MyFaces 2.1.9 / JSFマネージドBeanを使用すると、ページ全体の更新にかかる時間は2〜3秒です。

TomEE 1.5+ / CDI-managed-beansを使用すると、ページ全体の更新に5〜10秒かかり、場合によってはそれ以上かかることもあります。:(

理由を教えていただけますか？

昨日、TomEE 1.5+ / CDIマネージドBeanWebアプリケーションを運用サーバー（Windows 200332ビット4GBRAMおよび1TBのディスクスペース）に展開する前に、以下を読みましたが、実際には私の/この質問にはまったく答えませんでした。

Glassfishv3とTomcat7

PPRはFPRよりもパフォーマンスが優れていると読みましたが、セッションタイムアウト/管理の実装には次のことが含まれていました。

  1. LoginFilter（サーブレットフィルター）

  2. 次のh：head

meta http-equiv = "refresh" content = "＃{session.maxInactiveInterval}; url = pf_viewExpired.jsf"

CDIはJSFマネージドBeanよりも（時間）高価ですか、それともTomEEはCDIに最適なコンテナーですか？JBoss（またはWeld）がCDIのリファレンス実装であるか、それを持っていることを知っているので、JBoss/Weldを検討するのが最善かもしれません。

JSF管理のBeanからCDI管理のBeanへの移行（およびGlassfishからTomEEへの移行）のタスクを完了する前に、Glassfish/WeldでCDI管理のBeanWebアプリを起動する際に問題が発生しました。

上記の質問に答えるか、アドバイスしてください。ありがとう。

4

1 に答える 1

0

上記のコメントに示されているように、私はOpenEJB（TomEE）コミッターと協力してこの問題を解決しています。個人的には、この問題はおそらく次の原因によるものだと思います。

  1. アプリで定義および参照されるCDI管理対象Bean
  2. 考えられるCDIサイクリック参照（CDI 1.1で解決される可能性があります）
  3. 非常に大きなCDI@SessionScopedBean。アプリ内でビジネスロジック（またはタスク）を実行するために他の多くのCDIBeanを参照/挿入します。
  4. TomEE / OpenWebBeans（まだ開発中です）

したがって、答えはまだ決定されていません。この問題のために、次のOpenEJB JIRAを開きました（以下のURL）。興味があれば、このJIRAをお気軽にご覧ください。

TomEE 1.5.1 SNAPSHOT（およびCDI Bean）が本番サーバーで低速で実行されている

アップデート：

最近、TomEE / CDI-managed-beansは、本番サーバーでGlassfish / JSF-managed-beansと同じように機能しています。これは、最近次のことを行ったためです。

  1. 頻繁に使用される動的SQLを@entityという名前のクエリに置き換えます
  2. JPA createQuery（）およびcreateNamedQuery（）にクエリヒントを追加しました
  3. TomEEコミッターがrendered="＃{EL expression}"が6回呼び出されるとアドバイスしたため、頻繁に使用されるrendered = "＃{ELexpression}"を新しいファセットとui：include src = "＃{ELexpression}"に置き換えました。

そのため、TomEE / CDI-managed-beansは現在、本番サーバーで実行されており、パフォーマンスとエンドユーザーのレポート/エクスペリエンスを監視しています。

于 2012-11-27T04:26:32.427 に答える