2

Zend のビューは通常、即座にレンダリングされますが、データセットが大きくなります。1500 個のオブジェクトを xml ビューに追加すると、2 ~ 3 秒かかりますが、これは私のアプリでは受け入れられません。どんな提案でも大歓迎です。

4

2 に答える 2

3

600 KB では、アプリケーションの実行速度が遅くなる場合もあれば、できない場合もあります。実行時間は、実際のスクリプト、その永続層、Web からデータベース サーバーへの接続などによって異なります。したがって:

まず、サーバーサイド スクリプトの所要時間を計算するように、アプリケーションをインストルメント化します。

たとえば、次のように名前を変更index.phprealIndex.phpて新しいindex.phpものを作成します。

$startTime = microtime(TRUE);

require_once( dirname( __FILE__ ) . '/realIndex.php' );

$endTime = microtime(TRUE);

echo '<hr />Time taken: ' . ( $endTime - $startTime ) . ' micros';

確かに、このアプローチは取るに足らないものであり、あらゆる状況で機能するわけではありません。とはいえ、それは出発点です。

いくつかのデータを返すようにしてください

多くの場合、膨大な数のデータ項目 (XML であるかどうかにかかわらず) は、不適切な UX および技術設計を表しています。

したがって、サーバー側でできるだけ多くのデータを処理し、圧縮されたデータ セットをクライアントに返すことを提案します。忘れないでください: データベース システムは、データの取得と処理に関しては、スクリプトより多かれ少なかれ常に高速です。

ユーザーは 1500 項目の Web ページからすべてのデータを実際に頭で理解することはできないため、結果のビューの data をページングすることを提案します。ビッグ データ セットの 1/10 を取得し、前または次のページに移動するためのナビゲーション コントロールを提供します。

これはユーザーに役立つだけでなく、データベースが適切に定義されている場合、データベースがスキャンして取得する必要があるデータの量も削減することに注意してください。たとえば、検索する属性にインデックスを付け、固定サイズのテーブルにレコードを保持しようとするなど...

于 2012-09-08T23:09:04.190 に答える
0

三つのこと:

  1. プロファイリングを忘れてください。遅いと判断したことはありますが、これは当然のことです。1,500 セットのデータは大量のデータです。
  2. ページングを追加!1 ページあたりのアイテムの最大数 (制限) を決定し、ページング コントロールを追加します。
  3. 特にデータがそれほど頻繁に更新されない場合は、memcache などのキャッシュ ソリューションを検討してください。

これらの項目のいくつかは、別の回答ですでに対処されているようです。私たちは何かに取り組んでいることを意味する必要があります:-)

于 2012-09-09T16:24:40.933 に答える