+- Curl Global Community (https://communities.curl.com)
+-- Forum: Blogs (https://communities.curl.com/forumdisplay.php?fid=17)
+--- Forum: Tech blog (https://communities.curl.com/forumdisplay.php?fid=18)
+---- Forum: Baison log (https://communities.curl.com/forumdisplay.php?fid=27)
+---- Thread: Curlのパフォーマンスについて (/showthread.php?tid=1048)
Curlのパフォーマンスについて - umemura - 03-11-2014
★point
グリッドの内容をサーバで計算、チェックする場合は、
グリッド全体、もしくは、カラム単位で通信する方針で設計する
Curl は、とくにテクニックを用いずとも、かなり高速で処理できるので、
それほどパフォーマンスを出すための設計を意識する必要がないのですが、
グリッド（RecrodGrid）に関連したパフォーマンスの問題が出ることは、多々あると思います。
その場合でも、セルを拡張したクラスを利用しているケースなど、
オーバーライドした refresh-data メソッドの処理が重い、という内容であれば、
いくらかチューニングする方法がありそうです。
■RecordGrid のパフォーマンスについて
http://communities.curl.com/showthread.php?tid=232
むしろ厄介なのは、グリッド内のセルごとに、何らかの通信処理が行われるケースだと思います。
たとえば、セル内のコード値を元に、マスタテーブルから名称を取得したり、
日本円で入力した金額を、ある通貨のレートで計算するためにサーバに問い合わせたり。
こういったケースでは、初期表示や、チェック処理のタイミングで、全セルに対して処理を行うので、
セル数×通信時間 という待ち時間が発生することになりますが、
レコード数が少なければ待ち時間も短いため、
テストデータが少ない開発中は問題視されずに済んでしまい、
運用に入ったとたん、ユーザから大量データの入力が行われ、
長時間の待ち時間が発生し、障害として上がってしまう、ということがありそうです。
問題を解決するには、通信回数を減らす必要があるので、セル単位（レコード）ではなく、
グリッド単位、もしくはカラム単位で計算、チェック等を行えるよう設計すべきでしょう。
共通部品としてチェック機能などを実装する場合は、
レコードごとに計算やチェックの条件が異なっている場合にどうするかなど、
案件ごとの要件によってとくに工夫が要りそうです。
私も、セル単位での共通機能しか考慮せずに設計してしまい、
痛い目にあってきました。
何か良い設計指針、方法等をご存知の方、
こんな設計にしたよ、というノウハウを教えていただけるとありがたいです。