- PR -

DynaActionFormを使用して5000項目のアクセッサsetに100秒

1
投稿者投稿内容
はる
会議室デビュー日: 2006/01/28
投稿数: 2
投稿日時: 2006-01-28 01:04
9ias(oracle社)+struts1.1環境で本番環境に明細数を無制限に入力可能な画面
(1明細あたりの項目数はhiddenを合わせて60項目(表示項目30＋入力項目10))
が稼動しているのですが、DynaActionFormを使用して5000項目のアクセッサsetに
100秒かかっています。これは全体レスポンスの85%を占めています。
ヒープ領域の設定もいろいろ変更して試してみたのですが、
ヒープ領域が不足している様子はありませんでした。
カスタムtagを使用しているとレスポンス劣化を招くそうですが、
それでもアクセッサsetにはこんなに時間がかかるものなのでしょうか？
ちなみに明細数が少ない時(5以下)は全体で3秒程でレスポンスがあります。
Kissinger
ぬし
会議室デビュー日: 2002/04/30
投稿数: 428
お住まい・勤務地: 愛知県
投稿日時: 2006-01-29 16:45
はるさん、こんにちは。

更新前のデータの母数、ロックのレベル、
ハードディスクのアクセス速度、ＣＰＵ数…
にも依ると思います。

カスタムタグを疑うのでしたら、それを
使わない方法で試してみてはどうでしょう。
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2006-01-29 17:23
パフォーマンスの問題は、細かい単位で計測しなければ
正しい情報は得られませんよ。
ステートメント単位でボトルネックを探すべきです。

カスタムタグは、確かに超高速とは言えませんが、
単なるスクリプトレットの隠蔽と考えても差し支えないと思います。
CPU内で済む処理とI/Oに関連する処理とでは、
全然時間の単位が違います。

リクエストの受信から画面が描写されるまでを考えると、
ボトルネックになりやすいのが、
・無駄の多い業務ロジック
・データベース（下手なSQLやネットワーク速度を含む）
・ネットワーク
・ブラウザの描写
です。

どのステートメントが一番時間を要するかを
ログなどで出力してみると良いと思います。
どうしてもカスタムタグを疑うのであれば、
カスタムタグのクラスを継承して、ログ出力を行うような作りに変更し
時間の計測を行ってみるのもよいと思います。
山本 裕介
ぬし
会議室デビュー日: 2003/05/22
投稿数: 2415
お住まい・勤務地: 恵比寿
投稿日時: 2006-01-29 18:00
10項目の時、100項目の時、1000項目の時、2500項目の時と時間を計測してみてはいかがでしょう。
項目数に比例しているならそんなもんでしょうし、項目が増えるにつれて立ち上がっていく傾向が見られるのであればなにかチューニングの余地があるのかもしれません。
はる
会議室デビュー日: 2006/01/28
投稿数: 2
投稿日時: 2006-01-30 00:24
はるです。
皆さん、返信ありがとうございます。
多少補足させて貰います。

まず、ログを入れていろいろと確認した結果、遅いのはクライアントのリクエストをActionFormにセットする部分(org.apache.commons.beanutils.BeanUtils#populate)がボトルネックであることまでは判っており、ビジネスロジック(sql等)やネットワークがボトルネックでないことまでは確認できています。
populateのみの処理時間は項目数が283で0.3秒、1331で6.5秒、2641で23.6秒、3951で61.3秒、5261で102秒です。
グラフにすると項目数が増えるほど、1項目あたりの時間が右肩上がりの曲線になっております。皆さん、これって普通？？？

また、ご指摘頂いたようにカスタムタグを使わないようにして上記性能ボトルネック部分を再測定し、レポートさせて頂きます。

これが限界との意見が多ければ自信を持ってユーザに言えるのですが、自分自身この結果に半信半疑でユーザにも「もう少し詳細に調査します」といって早2週間。
皆さん、どうか助言をお願いします。
masa
大ベテラン
会議室デビュー日: 2005/05/11
投稿数: 108
投稿日時: 2006-01-30 00:40
引用:

はるさんの書き込み (2006-01-30 00:24) より:
まず、ログを入れていろいろと確認した結果、遅いのはクライアントのリクエストをActionFormにセットする部分(org.apache.commons.beanutils.BeanUtils#populate)がボトルネックであることまでは判っており、ビジネスロジック(sql等)やネットワークがボトルネックでないことまでは確認できています。
populateのみの処理時間は項目数が283で0.3秒、1331で6.5秒、2641で23.6秒、3951で61.3秒、5261で102秒です。

うーん。
そこまで分かっているならば、下の２つを試してみたいところです。

DynaActionFormのリフレクションがボトルネックになっていると仮定して

１．DynaActionFormの使用を辞めてActionFormを使用する。
２．jdkのversionが古い場合、versionを上げてみる。
　　（versionが新しいほどリフレクション使用時の速度が改善されています。）


[ メッセージ編集済み 編集者: masa 編集日時 2006-01-30 00:42 ]
1

スキルアップ／キャリアアップ（JOB@IT）