ページ移動していると求頼変数 kno
が付くのが気になっていたが,中景輪符の知名からの輪結で,前景知番を付けていたことが分かった。ただ,何の意図だったかはっきり思い出せない。恐らく,デライト開発初期に,戻る機能でも付けようとしていたのだろう。
いずれにせよ現時点では使っておらず,表示位置によって輪結先が変わるとクロール効率にも影響しそうなのでいったん削除。
kno
}{希哲16年9月23日}{希哲16年9月23日の開発}{希哲16年9月23日の進捗}{影響しそう}{使っておらず}{付けようとしていた}(37)_dg
}{想定を越える}{複合索引}{後景時印}(74)一部の輪郭の応答速度が異常に遅い現象があったが,どうもこれは最適化系が混乱していたせいらしい。前後景輪の取得部分で遅くなっていることは把握していたが,輪括量にかかわらずあったため不可解だった。
ts_fg
,ts_bg
の追加後も,多少の改善は見られたものの,まだ異常な遅さの範疇だった。現象が不安定なので,不安定な要素に起因していると睨んで実行計画をよく観察してみると,_dg
の時印の索引が選択されている時に知番の索引が使われていないことに気付いた。
そこで,前景知番と後景時印,後景知番と前景時印の複合索引にすると,全ての求頼でしっかり索引が使われるようになり,把握していた全ての当該輪郭の問題が解消した。さらに,低負荷求頼でも索引が有効利用されるようになり,想定を越えるデライト高速化に繋がった。膨大な輪括量が問題だとすると捌き手の性能の限界かもしれないと思っていたのでこの不安が無くなったのも大きい。