これは極端な大当たりですが、ボンネットの下で何が起こっているかを知っているエンジニアがここにいることがあります。
まず、ほとんどの場合、コードを書き直して QoQ を回避し、パフォーマンスを大幅に向上できることを知っています。しかし、私がデバッグしようとしているのは、将来のプロジェクトのガイドラインを作成するために、特定の条件下で QoQ を使用するコードのパフォーマンスが非常に低下する潜在的な理由です。
1) QoQ システムへのアクセスをシングル スレッドにする ColdFusion QoQ Java 実装について何かありますか? （これについて Railo の投稿を見ました）
2) FusionReactor によると、スタック トレースには常にQoQの評価フェーズ (90% の可能性) または実行フェーズ (10% の可能性) にリクエストがあり、それを取り巻くロジックの他の部分はありません。それは、クエリ パラメータを使用してループで実行されていることです。
ベスト プラクティスであるかどうかに関係なく、レポートを生成するために何万回もの繰り返しで QoQ を使用するいくつかの異なる機能があります。速度が低下する唯一のプロセスは、QoQ を使用するプロセスです。サーバーの再起動直後に開始しない限り、完了するまでに 10 倍の時間がかかります。FusionReactor は、QoQ の評価時または QoQ の処理時に常にスレッド状態を保持します。注意: ヒープと CPU は、全期間を通じて 20% 未満で安定しています。コードキャッシュ、perm など、すべてのメモリ空間が良好に見えます。
ループでQoQ を実行することは、それを実行する方法ではなく、変更する必要があることを知っていますが、答えを探しているだけです。コードはロックされていますか？それは利用可能なスレッドの問題ですか？声明の評価について何かありますか？再起動直後は問題ないのに、数時間以内に急速に劣化するのはなぜですか? それが私を悩ませているものです-私はそれがいつも永遠にかかっても大丈夫です.スタックオーバーフローに陥るのは奇妙なパターンです.
役立つ場合は、ColdFusion 10。