2

このテーブルには数百万のレコードがあるため、最初にデータベースログテーブルにクエリを実行して、最適化されたクエリから関連するすべてを取得し、必要なものだけを選択し、関連する開始IDと終了IDを取得する分析チャートがあります。最初のクエリが取得されると、ColdFusionのクエリクエリを使用してそのデータを処理し、さまざまなグラフを表示します。

この例では、実際の外部データベース呼び出しが31ミリ秒で2,240レコードを取得していることがわかります。

qryGetLogs (Datasource=ourDSN, Time=31ms, Records=2204)

曜日ごとの1時間あたりのビューを表示し、それらを表示するjQueryチャートを作成するチャートがあります。初期の設計から、これらのクエリの実行時間はほとんど無視でき、ほとんどの場合0msでした。1日（24）の1時間ごとに週7日間ループするため、これは168クエリです。これは、外部DB呼び出しをそれほど頻繁に行わない主な理由の1つです。

すべてではありませんが、これらのクエリのクエリの多くは、最初のデータベース呼び出しよりも実行に100倍以上時間がかかっているようです。それらのほとんどは、BETWEEN日付範囲関数を使用して、各曜日と時間の部分のレコードを選択しています。

qryViewsPerHour (Datasource=, Time=4312ms, Records=5)
SELECT createdOn, DayOfWeek
FROM qryGetLogs
WHERE  (CreatedOn BETWEEN '2012-09-03 0:00:00' AND '2012-09-03 0:59:59')
AND (DayOfWeek = 2)

別のクエリのクエリは4,312ミリ秒かかり、2,240レコードのクエリを検索していたことがわかります。次のクエリの多くのクエリ時間は次のとおりです。

qryViewsPerHour (Datasource=, Time=4610ms, Records=5)
qryViewsPerHour (Datasource=, Time=4187ms, Records=8)
qryViewsPerHour (Datasource=, Time=5062ms, Records=6)
qryViewsPerHour (Datasource=, Time=3985ms, Records=0)
qryViewsPerHour (Datasource=, Time=4828ms, Records=2)
qryViewsPerHour (Datasource=, Time=5750ms, Records=0)
qryViewsPerHour (Datasource=, Time=3016ms, Records=4)
qryViewsPerHour (Datasource=, Time=3625ms, Records=6)
qryViewsPerHour (Datasource=, Time=6265ms, Records=11)

したがって、これらのクエリだけでわかるように、読み込み時間が40秒追加されました。ただし、次のクエリはわずか78ミリ秒で、前のクエリよりも多くのレコードがあり、その後は多くの場合、時間が短縮されていることに注意してください。

qryViewsPerHour (Datasource=, Time=78ms, Records=18)
qryViewsPerHour (Datasource=, Time=62ms, Records=7)
qryViewsPerHour (Datasource=, Time=63ms, Records=12)
qryViewsPerHour (Datasource=, Time=78ms, Records=34)
qryViewsPerHour (Datasource=, Time=78ms, Records=9)

それらはしばらくの間良い時を過ごし、それからBAM！2〜6秒のクエリに戻ります。

qryViewsPerHour (Datasource=, Time=4891ms, Records=13)
qryViewsPerHour (Datasource=, Time=1984ms, Records=8)
qryViewsPerHour (Datasource=, Time=4875ms, Records=4)
qryViewsPerHour (Datasource=, Time=6203ms, Records=0)

全体として、ロードに数秒かかっていたのは、100〜400秒のロードにかかっていました。これは、単なる週次レポートです。月報にも使用しています。

サーバーを監視し、リクエストを実行しているのは自分だけであることを確認したので、CPUのリソースが他の人に消費されていないことを確認しました。また、CPUリクエストも監視しており、安定して安定しています。 JRUN.exeによって使用されます。

誰かがこの問題について何かアドバイスがありますか？それは私を狂わせています！

助けてくれてありがとう。

4

4 に答える 4

12

通常、クエリ オブ クエリは驚くほど高速です。ただし、ボリュームが増えるとさらに時間がかかる場合があります。ColdFusion のドキュメントで推奨されている 5,000 ～ 50,000 行の範囲内に収まっているため、これは 1 つのことしかありません。結果を得るために一部のデータが変換されている場所。この場合は、指定した日時です。時間値には先行ゼロが 1 つあります。私はそれが奇妙に聞こえることを知っています。

変更: WHERE (CreatedOn BETWEEN '2012-09-03 0:00:00' と '2012-09-03 0:59:59')

TO: WHERE (CreatedOn BETWEEN '2012-09-03 00:00:00' AND '2012-09-03 00:59:59')

これをテストしたところ、結果がより優れていることがわかりました。

于 2012-09-06T14:20:38.033 に答える
3

Coldfusionには、私の経験ではクエリのクエリを実行する機能がありますが、これは最後の手段です。それがいかに非効率的で制限されているかという理由。CFはプログラミング言語であり、SQL言語ではないため、実際のDBが持つような最適化機能はありません。

代わりにクエリをデータベースにプッシュすることを強くお勧めします。ビューをサポートするDBがある場合は、元のクエリに基づいてビューを作成することもお勧めします。これにより、元のテーブル全体ではなく、ビューに対してサブクエリを実行するだけで済みます。

特に大規模なデータセットを操作する場合は、クエリのクエリをできるだけ避けてください。すべてのデータセットを大量のJavaオブジェクトとしてメモリに保存する必要があるためです。Russが指摘したように、ガベージコレクターの影響を受けやすく、レポートが大きくなると、メモリ不足の問題が発生する可能性があります。（私はかつて特大のQoQでPCをノックオーバーしました）

于 2012-09-06T11:31:19.157 に答える
2

JVM ガベージ コレクタが動作しているように思えます。1 つのオプションは、JVM 監視ツールを実行して、特定のニーズに合わせて JVM を調整することです。別のオプションは、クエリのクエリではなく、データベースでサブクエリを実行することです。

于 2012-09-05T22:56:26.703 に答える
1

サーバーに往復するよりも良いと思っていたので、投稿してよかったです。

しかし、次を使用するのはどうですか:

cachedWithin="#CreateTimeSpan(0,0,1,0)#"

それはクエリのクエリと同じくらい良いかもしれません。

于 2012-09-06T15:39:18.183 に答える