数百以上のテーブルを使用するシステムを開発しています。
画面遷移に2～8秒もかかるので、解析したところ、DAO、Logic、Action等、アプリケーション側では遅れはなく、S2のフレームワーク側が問題の様です。
何が原因なのでしょうか？
また、どのような対処方法があるでしょうか？
| ＜発生環境＞ | |
|---|---|
| OS | Any |
| JDK | Any |
| Vender | Sun |
| Seasar2 | S2Container2.3.7 |
- ＜A17-1＞
- S2Container2.3.7以前では、diconファイルを細かくincludeで分割しすぎると、コンポーネントの検索が線形検索に近い状態で処理されるためです。
今回は、S2DaoMakerを使用しているので、1つのdiconに1つのコンポーネントを定義し、それらをincludeするような構成になり、パフォーマンスが劣化します。
対処方法として、1つの dicon になるべく多くのcomponent定義を記述し、アプリケーション全体の diconファイル／include 定義が少なくなるようにすると、改善されます。
例えば、次の条件で定義を行う場合を考えます。
・app.diconに100個のdiconを定義し、各dicon内でalldao.diconをincludeしている。
・alldao.diconでは200個のdiconを定義し、各dicon内にDaoが定義している。
すると、以下のようなdicon構成になります。
app.dicon ├─alpha1.dicon │ └─alldao.dicon │ ├─mydao1.dicon <--- 1回目の検索 │ │ └─MyDao1 │ ├─mydao2.dicon <--- 2回目の検索 │ │ └─MyDao2 │ │ ・ │ │ ・ │ │ ・ │ └─mydao200.dicon <--- 100回目の検索 │ └─MyDao200 ├─alpha2.dicon │ └─alldao.dicon │ ・ │ ・ │ ・ └─alpha101.dicon <--- 20001回目の検索 └─<検索対象Component> ※図の順でdiconファイルに記述されているものとします。 ※分かりやすさのため、末端のdiconでの検索のみを数えています。この構成で<検索対象Component>を検索すると、alldao.dicon内のdiconに対して20000(=100×200)回もの検索処理が実行された後、<検索対象Component>を発見します。
dicon定義を修正し、以下のようにalldao.dicon内で直接200個のDaoを定義することで、20001回の検索処理が101回になります。
app.dicon ├─alpha1.dicon │ └─alldao.dicon <--- 1回目の検索 │ ├─MyDao1 │ ├─MyDao2 │ │ ・ │ │ ・ │ │ ・ │ └─MyDao200 ├─alpha2.dicon │ └─alldao.dicon <--- 2回目の検索 │ ・ │ ・ │ ・ └─alpha101.dicon <--- 101回目の検索 └─<検索対象Component> ※図の順でdiconファイルに記述されているものとします。 ※分かりやすさのため、末端のdiconでの検索のみを数えています。
Copyright(c) SMG Co., Ltd. All Rights Reserved.