0

そのため、ホスト上で Cron を使用して展開および実行され、データベース テーブル内のすべてのレコードにインデックスを付けるこの cron スクリプトがあります。インデックスは、後でサイトのフロント エンドとバック操作の両方に使用されます。

操作後のインデックスは約 3 ~ 4 MB です。

問題は、多くのリソース (CPU: 30+ と大量のメモリ) を消費し、マシンの速度が低下することです。私の質問は、以下に説明する操作を最適化する方法についてです。

最初に、Zend Framework API を使用して構築された選択クエリがあり、このクエリは次に、インデックス付けされている現在のアイテム数のバランスを取り、あまりにも多くのアイテムを反復しないようにするために使用しているページネーターを返すページネーター ファクトリに渡されます。スクリプトは、最後に到達するまで foreach ループを使用して paginator オブジェクトの現在のアイテムを反復処理し、次のページのアイテムを取得した後、最初から開始します。

このオーバーヘッドは Zend_Lucene が原因ではないかと疑っていますが、これを改善する方法がわかりません。

4

1 に答える 1

1

Zend Framework インデックスのサイズを予測できますか?に対する私の回答を参照してください。

Zend_Search_Lucene と Apache Lucene (Java バージョン) をテストしました。私のテストでは、Java 製品は PHP 製品よりも約 300 倍速く 150 万のドキュメントをインデックス化しました。

Apache Solr (Apache Lucene の Tomcat コンテナー) を使用すると、より快適に作業できます。Solr には、JDBC データ ソースから直接データを取得するDataImportHandlerというツールが含まれています。

PHP から Solr と通信するには、PECL Solr拡張機能を使用します。その PHP 拡張機能をインストールできない場合は、PHP の既定のインストールで利用できるはずのCurlを使用してください。

于 2010-04-24T19:03:39.593 に答える