[Java]JPAのマッピングに時間がかかりすぎる件について

Question

現在Java（SpringBoot）でJPA（Hibernate）を利用してDBサーバーと通信するWEBシステムを作成しております。
JPAで取得したデータはEntityクラスを用意し、そこにマッピングして受け取るようにしています。

そこで問題があるのですが、データ量が少なければ問題ないのですがマッピングする量が増えた時、レスポンスが著しく遅くなることが分かりました。
調べたところwebサーバーとDBサーバーの通信時間、DBサーバーのレスポンス時間は問題ありません。

JavaでEntityクラスにマッピングする際時間がかかることが分かりました。
今までNodeなどでは発生しなかった問題なので、解決策が見つからず途方にくれています。
とりあえず現在はデータ量に制限を設けることで、問題を先送りしています。
具体的には検索時に、レスポンスの件数が100件以上であればエラーして絞込の条件を増やすように促すなどです。

entityクラスのフィールドを制限し、マッピングする項目制限をするなどもあるのでしょうが、現状使わない項目でも随時利用していくことになるでしょうし（本当に使わない項目であればそもそもDBのテーブル構成から検討する必要がありますが）、出来ればマッピングクラスはDBの全項目をフォローしたいところです。

サーバースペックの問題も勿論あると思いますが、多少良いサーバーを用意して実験してもさほど結果は変わりませんでした。
具体的には1000件の項目の多いテーブルデータを取得してブラウザに表示するまでに15秒かかりました。
Javaでクラスにマッピングするとなると、こんなものなのでしょうか。

何か良い解決方法があれば、ご教授願います。

Comments

[jcs502ulf]

当該テーブルのカラム数はどの程度でしょうか？

[rontec]

ご返信ありがとうございます。
今職場じゃないので明確には分からないのですが、10や20ではなかったと思います。
joinして他テーブルとの結合もあったので、30や40以上はあったかもしれません。

Answer 1

windows2012server,での実績です。
結合テーブル数20個、union5個、sqlステップ数約300行
sql実行結果最大数1700件、平均1200件、カラム数33個、
データベースはcache です。
dbにjdbc 接続、sql実行し、オラクルに全レコードinsert
cache -> java に dtoリストへのresultset から詰め替え処理に
1秒以下、oracle insert 完了までの平均時間2.5秒。

oracle -> java -> web response をJson形式で出力する
までの実行時間は、2秒、サーブレット処理完了から、画面一覧表示
完了までの時間が初回、14秒、平均11秒、トータルで15-17秒くらい
です。
ie9,11での実績値です。
firefox22,33 では、画面表示に掛かる時間(javascriptのonload
実行から、画面が表示されて、スクロールバーが触れるようになるまで
の時間が平均6秒です。サーバー処理と合算すると平均9秒になります。

1000件のレコードをhtml table タグで表現したとき、ie9の表示不具合が
解消できなかったので、無限スクロール機能を持った一覧表示スクリプトで
一覧表示を実装しました。

1700件、30カラムのテーブル一覧表示で、ie9はハングアップに近い状態に
なりました。ie11でも同様です。1000件30-40カラムで15秒は妥当だと思います。

dbの結果 to list<OriginalEntity> の部分はリフレクションで、
dbの取得型は、double,int,string,で、oracle はdoubleじゃなくて
bigdecimalで取れるので、4つの型の相互変換と、リスト、マップの自動製成、
処理を自前で作成しました。余計なチェック処理、型変換処理が無い分、
beanutils のソレよりはほんの少しだけ早く動作しますが、1000件くらいでは
あまり変わりません。

カンバセーションセッションとかあるなら、jsonデータの遅延読み込みと、
無限スクロールする一覧script で、画面表示から画面を触れるようになるまでの時間を
3秒くらに短縮できます。

無限スクロール一覧
w2ui table

以前のプロジェクトでは、jpaりようの条件は、対象テーブルに1000件以上のデータがあるテーブルとjoinするか、だったと思います。jpaの仕組み上、3つの join は、3つのselect 分割されて、3テーブル共javaに読み込んでからjava側で結合するので、対象データが増えるほど、検索対象外のデータを無意味にキャッシュしてしまう特性が仇になったことを覚えています。

1000件15秒はそんなもんです。
sql -> java
java -> web response
web response -> browser
browser -> 一覧触れる
各ポイントの実行時間を測ってみた方がいいですよ。jpa絡むと遅いのはわかってるので、1000件の単純なクエリで結果取得から、画面表示まで。一番遅いのは、ブラウザです。

1000件ともなると、表示は解決できたとしても、一番肝心の操作性が劣化します。具体的には、スクロールがモッサリする。ie9互換モードなら、tablesorter プラグインは、firefox同等の性能だが、ie11を含め、標準モードでは動かない。ie9,11とも、30カラム以上のテーブル表示に納得できない不具合が発生する場合がある。

以上です、長々とすみません。

Comments

[rontec]

実験データまで載せた詳しいご解説ありがとうございます。
件数については現状テスト用DBにあるデータ数の問題で、実際1000件をブラウザ表示するつもりはありませんが、100件という制限が正直少々少ないような気はしていました。

JPAが時間かかる件は一般常識なんですね。
classへのマッピングが便利な反面、少々使いづらさもありますね。

今回IEがメインターゲットのシステムなので、不具合は困りますね…。
とはいえスクロールが発生しない量しか一度に表示しないので大丈夫だとは思いますが。
参考にさせて頂きます。

[ipadcaron]

テーブル描画時に、３２カラム目と３３カラム目が一部だけ、３３カラムと３４カラム目に表示されます。スクロールしようが、テーブルを再描画しようがこのバグが一度発生すると再起動しない限り治りません。治ると言ってもそのときたまたま現象が再現しない、程度の治るであって、根本的な解決方法は時間がないのでやめました。
エビデンスも取ってあるのですけど、ここには会社の都合で載せられません。

３３カラム、１２００行一覧表示の画面は現在本番環境にて稼動中です。テストデータによる実績ではなくて本当の話です。

ページングでも問題になる場合があります。
特にカラム数が多い場合、気をつけてくださいね。
５０行前後なら大丈夫なんですが、、、１００％再現しない行数・カラム数の関係はわかりません。

ページングで行うなら、操作性を向上するという前提を科すことで、一覧表示行数は２０ー３０行程度に抑え、２５カラム以上表示する場合は、４０カラムまでOK だが、４０カラム中２０カラム選択表示としたい、などとごねるのが良いかと。

Edge ブラウザ対応ではなく、おそらく、メインターゲットはIE11 だと思います。
jquery-ui は標準モードでないと動きませんが逆に、tablesorter などの jquery プラグインは標準モードでは意図した通りに動作しません。ご注意ください。
あくまでも、1000行表示させたときの話なので、５０行程度なら表示カラム数だけ
気をつける以外なんでもできるでしょう。