以前のことですが、igGridを、自作のWebサービスを介して、背後のDBにあるテーブルと接続して使っていたことがありました。
その際に、テーブルが大きくなると、igGrid自体が非常に遅くなる問題が発生したことがあります。
通常の業務用DBなので、トランザクション系のテーブルは結構大きいものがいくつもあって放置できない問題です。
問題
igGridPagingを使っていて、ページ数が非常に多い時、igGridが非常に遅くなる。
問題が発生すると、CPUの使用率が急激に上昇し、igGridに限らずすべてのアプリケーションの操作が遅くなりました。
原因
igGridのようなJavaScriptライブラリで問題が発生したら、開発者ツールを開き、デバッガやネットワークタブなどで不審な動作がないか確認すると思います。
このときは、ネットワークに不審な通信はありませんでした。
igGridのデータソースはリモート(Webサービス)で、今のページに必要な分だけデータを取得して来るロジックです。
普通に考えると遅くなりようがなさそうです。
しかし、igGridPagingが持っているイベントに関数を設定してデバッガで止めたりして調べたところ、どうも、現在表示していないページ分も何らかのDOM操作をしているような挙動をしていました。
例えば、テーブルに50000行あって、１ページ20行であれば、2500回イベントを通って何かを追加しているような挙動をしていたのです。確か、イベントに設定した関数中で変数をカウントアップして確認しました。
対策
こういうときは、APIドキュメントを確認して、余計な挙動を止めるオプションがあればよいのですが、このときは発見できませんでした。
しかたないので、最初にページを表示する時(Webサービスでなく、ページのレンダリング時)に対象テーブルの全件数をSQLでカウントし、一定数以上あったらページング機能を無効にする対処をしました。
ページングを無効にしただけだと表示できないデータがあって不便なので、「データが多すぎるのでフィルタで絞り込みをしてください」のようなメッセージを出力。igGridFilteringも有効にし、ユーザが入力したフィルタ条件で閾値を下回る件数になったら、igGridPagingを有効に戻すという対応です(ちょっと記憶が曖昧です。もしかしたら、igGridのgrid_pagerを非表示にするなどで対応したかもしれません。重要なのはページャに過大なページ数が設定されないことです)。