SQL
{希哲16年9月18日の開発 K#F85E/E74C-5BA7}
宇田川浩行最初の中間出振るいに成功。これにより,全知検索の応答速度,柔軟性,交度品質が大きく向上した。出振るい作業も円滑に進み,手溢れも無く,全体として大成功だった。
輪郭情報取得改良
まず,期待通り,輪郭情報取得方式の改良により応答速度が大きく向上した。体感的にも,この種のサービスとしては並という程度から,はっきり速いと言える程度になり,快適度が数段上がった感覚がある。
これまでのデライト高速化施策の中でも最大級の効果を感じるが,これはボトルネック解消によるところが大きい。6月の Cμ 文字列処理改良あたりから,領下手定め環境での高速化効果の大きさに比べて本番環境での効果がかなり小さいと感じるようになっていた。考えられるボトルネックは,相振り・出場間の通信回数が多過ぎる輪郭情報取得処理だった。
これまで,ページに表示される輪郭情報の取得は,相振りから大体次の流れで行っていた。
- 輪郭隠しにない吊るし輪郭があれば輪郭情報を取得する(
dg_oln()
)。 - 輪郭一覧の輪郭情報を取得する(
dg_fnd()
か,吊るし輪郭の初期状態はdg_fg()
,dg_bg()
)。 - 各輪郭の自我情報・前後景輪情報を個別に取得する。
{希哲16年7月15日12歩 K#F85E/E74C-70FE}
宇田川浩行14時過ぎ,用者の指摘で2ページ目以降の読み込みが異常に遅い問題に気付き,急遽修正作業。
結局,一昨日出振るいした公開設定機能で,SQL::cnd_prm_rd()
が生成する条件式が上手く使えていなかった問題だった。直感的に問題なさそうな単純な条件式だったことと,管理者の自我では無効化していたことで気付かなかった。
1時間ほど SQL や索引をこねくり回して改善しなかったため,残しておいた dg_b_prm_rd()
を使ってみたら,これで問題ないことが分かった。とりあえず,SQL::cnd_prm_rd()
で dg_b_prm_rd()
の呼び出しを生成するようにしておいた。
もともと dg_b_prm_rd()
を使うつもりで実装したが,索引の利用などで将来的に問題がありそうな気がして条件式生成に切り替えていた。意外にも反対の結果となった。簡単な手定めではわずかに条件式の方が速い程度だった。条件式生成にもまだ確信が持てず残しておいたのが良かった。
とりあえず実用上の問題は解消したが,手定めしながら今後の課題についても把握しておいた。