Zend のビューは通常、即座にレンダリングされますが、データセットが大きくなります。1500 個のオブジェクトを xml ビューに追加すると、2 ~ 3 秒かかりますが、これは私のアプリでは受け入れられません。どんな提案でも大歓迎です。
2 に答える
600 KB では、アプリケーションの実行速度が遅くなる場合もあれば、できない場合もあります。実行時間は、実際のスクリプト、その永続層、Web からデータベース サーバーへの接続などによって異なります。したがって:
まず、サーバーサイド スクリプトの所要時間を計算するように、アプリケーションをインストルメント化します。
たとえば、次のように名前を変更index.php
しrealIndex.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 を取得し、前または次のページに移動するためのナビゲーション コントロールを提供します。
これはユーザーに役立つだけでなく、データベースが適切に定義されている場合、データベースがスキャンして取得する必要があるデータの量も削減することに注意してください。たとえば、検索する属性にインデックスを付け、固定サイズのテーブルにレコードを保持しようとするなど...
三つのこと:
- プロファイリングを忘れてください。遅いと判断したことはありますが、これは当然のことです。1,500 セットのデータは大量のデータです。
- ページングを追加!1 ページあたりのアイテムの最大数 (制限) を決定し、ページング コントロールを追加します。
- 特にデータがそれほど頻繁に更新されない場合は、memcache などのキャッシュ ソリューションを検討してください。
これらの項目のいくつかは、別の回答ですでに対処されているようです。私たちは何かに取り組んでいることを意味する必要があります:-)