9

私は仕事用のWebサイトを構築していますが、より重要な機能の1つは、データを表示するリッチコンテンツグリッドです。デフォルトでは、ページごとに20個のアイテムしか表示されませんが、データベースには、フィルタリング、並べ替え、検索が可能な最大200個のアイテムがあります。

当社の営業およびマーケティングチームは、すべてのデータを1か所に表示し、データをページごとに表示するのではなくスクロールできるように、「すべてリスト」機能も要求しています。

Flexigridデータ

このシステム全体は、サーバー側でASP.Net MVC、クライアント側でjQueryとFlexigridを使用して構築され、JSONを使用してAJAXを介して2つの間でデータを交換します。

実際のデータ転送部分はかなりしっかりしています。20件の結果のページはリクエスト全体で800msかかります（Flexigridを介してサーバーにリクエストをPOSTし、レスポンスを取得します）。時間がかかるのは、クライアント側の処理です。

クライアント側の処理の一部をサーバーにオフロードできます。ただし、これによりサーバー側の操作に時間がかかり、返されるドキュメントのサイズがはるかに大きくなります。高速インターネット接続の状況では問題ありません...しかし、必ずしもそうとは限りません。

私が持っている他のオプションは、できるだけ多くのデータをダウンロードし、データ処理の大部分をクライアントにシフトすることです。これにより、リクエスト時間が基本的にnilに短縮されます（データセット全体ではなく、変更された要素のみをフェッチします）。高速のCPUと大量のRAMを搭載したマシンではかなりうまく機能しますが、必ずしもそうとは限りません。

少なくとも1人がこれを「本当の質問ではない」とフラグを立てたので、はっきりさせておきます...

  • データ転送時間の問題が発生するほど多くの処理をサーバーに移動することなく、クライアント側の処理時間の問題を軽減するために何ができるでしょうか。
  • クライアント側の処理とサーバー側の処理のバランスを取る場合のベストプラクティスは何ですか？
  • サーバー側またはクライアント側でエラーを発生させる方がよいでしょうか。
  • 物事がうまくいかないように、これらの交換をより適切に最適化するために使用できるツールは何ですか？
4

3 に答える 3

2

そんなに時間がかかっているクライアント側で何を処理していますか? JSON オブジェクト (非常に大きなものであっても) の処理は、あまり集中的であってはなりません。

クライアント側のデータを記述する際に DOM ルックアップが大量に発生すると、速度が低下する可能性があります。DOM ルックアップを減らすと、パフォーマンスが大幅に向上します。サーバー側とクライアント側の処理のバランスをとるための良い方法は、サーバー上でエラーを起こすことだと思います。サーバーはお客様の管理下にあるため、いつでもサーバーのアップグレードを選択できます。サーバー上で処理の大部分を保持することで、モバイル デバイスや古いコンピューターでも処理が容易になります。

ユーザー エクスペリエンスを向上させる方法で、AJAX とクライアント側の機能を利用する必要があります。ユーザーの要求に応じて、データをロードして処理します。彼らが要求したものだけをロードすることで、サーバーとクライアントの負荷を減らすことができます.

同じ種類のデータを何度も要求している場合は、サーバー側とクライアント側の両方のキャッシュを調べることができます。キャッシュを利用することで、リクエスト時間や帯域幅を削減できます。

于 2011-11-02T05:44:15.810 に答える
1

結局のところ、問題は、私が扱っているデータよりも、クライアント側の JavaScript エンジンにあります。私は一日の大半をプロセスのベンチマークとさまざまな操作のタイミングに費やしてきました。

すべてが Chrome ですばやく実行されます。Firefox では、すべてがかなり高速に実行されます (Chrome ほど高速ではないと思われます)。実際のパフォーマンスの遅れは Internet Explorer です。

データ セット全体 (200 行すべて) をロードすると、Flexigridはテーブル内のすべてのセルに対して何らかの後処理を実行しようとします。スクリーンショットでわかるように、各行には 29 個のセルがあります。つまり、一連の書式設定操作を合計 5800 回調べています。

より高価な操作 (jQuery オブジェクトの作成など) の一部を下位レベルのセル ループから引き出すことができたので、行ごとに 1 回だけ実行されましたが、最終的にはまだ IE 関連のパフォーマンスの問題が発生しています。

実際のベンチマークを提供するために、特定のイベントに到達するまでの合計時間を出力するようにコードを設定しました。

  • populateブラウザが最初に XHR リクエストを送信したときに発生します
  • addDataリクエストが返された後、JSON オブジェクトが解析される前に発生します
  • addCellPropデータの最初の解析後に起動し、テーブル内の各セルを反復します
  • doneすべてが終了すると発火します

20 行のデータを処理する (デフォルト):

------------------------------------------------------
| browser | populate | addData | addCellProp | done  |
------------------------------------------------------
| Chrome  | 0        | 84      | 123         | 286   |
| IE9     | 0        | 151     | 309         | 799   |
| IE8     | 0        | 226     | 481         | 1105  |

完全なデータ セット (このマシンでは 179 行) の処理:

------------------------------------------------------
| browser | populate | addData | addCellProp | done  |
------------------------------------------------------
| Chrome  | 0        | 318     | 669         | 1963  |
| IE9     | 0        | 157     | 1813        | 9428  |
| IE8     | 0        | 229     | 2188        | 13335 |

最もコストのかかる操作は ～ の間addCellPropですdone。コードをできる限り効率的にするようにしましたが、データ セットを何度も繰り返し実行している場合、特に DOM を操作する場合は、できることは限られています。

Flexigrid を変更して (多くの推奨事項にもかかわらず) DOM にできるだけ触れないようにしました。これにより、実際にはかなり高速化されました。この調査を開始したとき、IE9 でイベントが発生するまでに 20 ～ 30 秒かかりましたdone。

ここでの残念な真実は、すべてのプラットフォームが同じように作られているわけではなく、IE がこの方法でディスプレイ内のデータを操作するのに最適なエンジンではないように思われることです。

IE に頼って生の JSON オブジェクトからマークアップを作成するのではなく、サーバー側で HTML テーブルを作成して操作し、IE ユーザーに要求されたときに全体 (マークアップとすべて) をブラウザーに送信する方がよい場合があります。

于 2011-11-02T23:13:12.843 に答える
0

データ転送時間の問題が発生するほど多くの処理をサーバーに移動することなく、クライアント側の処理時間の問題を軽減するにはどうすればよいでしょうか?

データはデータベースから取得されますか? その場合は、そこでデータを制限してください。これは、db が得意とすることです。私は flexigrid を使用し、すべてのページングの並べ替えとフィルタリングをそこに保持します。データベースは、要求に応じてソートおよびフィルタリングされた必要なデータのみを返します。サーバーがしなければならないのはそれを返すことだけであり、クライアントがしなければならないことはそれをレンダリングすることだけです。

クライアント側の処理とサーバー側の処理のバランスをとる際のベスト プラクティスは何ですか?

クライアント側をできるだけ軽く保つ

サーバー側とクライアント側のどちらでエラーを起こしたほうがよいですか?

はい、サーバーははるかに強力です

事態が悪化し続けないように、これらの交換をより最適化するために使用できるツールは何ですか?

IE 開発者ツールは、[ネットワーク] タブを使用して、ネットワーク経由で何が送信されているかを確認します

于 2011-12-22T10:38:05.280 に答える