{希哲16年9月18日の副日記}{適用される}{着手した}{大変だった}{一山越えた}{解決時}{複雑な交度}{検索結果改良}{不具合多発}{クロール頻度}...=}(238)

{希哲16年9月18日の開発 K#F85E/E74C-5BA7}

新生全知検索整備

最初の中間出振るい成功これにより全知検索応答速度柔軟性交度品質大きく向上した出振るい作業円滑に進み,手溢れ無く全体として大成功だった。

輪郭情報取得改良

まず,期待通り輪郭情報取得方式改良により応答速度大きく向上した体感的にもこの種のサービスとしてはという程度から,はっきり速い言える程度になり,快適度数段上がった感覚がある

これまでのデライト高速化施策の中でも最大級の効果感じるが,これはボトルネック解消によるところが大きい6月Cμ 文字列処理改良あたりから,領下手定め環境での高速化効果大きさ比べて本番環境での効果かなり小さい感じるようになっていた。考えられるボトルネックは,相振り出場間の通信回数多過ぎる輪郭情報取得処理だった。

これまでページ表示される輪郭情報の取得は,相振りから大体流れ行っていた

  1. 輪郭隠しにない吊るし輪郭があれば輪郭情報取得するdg_oln()
    1. 自我隠し存在しなければ自我情報取得するdg_ego()
    2. 前景輪数n_fg1以上なら前景輪情報取得するdg_fg()
    3. 後景輪数n_bg1以上なら後景輪情報取得するdg_bg()
  2. 輪郭一覧輪郭情報取得するdg_fnd() か,吊るし輪郭初期状態dg_fg()dg_bg()
  3. 各輪郭自我情報前後景輪情報個別に取得する
    1. 自我隠し存在しなければ自我情報取得するdg_ego()
    2. 前景輪数n_fg1以上なら前景輪情報取得するdg_fg()
    3. 後景輪数n_bg1以上なら後景輪情報取得するdg_bg()

この旧方式では,KNEST 隠し一部でしか活用出来ておらず中景輪数応じて求頼増え過ぎる問題があった1ページあたり最大45回求頼発生する可能性があったことになり,当然相振り出場間の通信コストそのまま応答速度低下繋がっていた

KNEST 隠し実装一段落させた6月30日の開発まとめた方針基き,これを次のように改良した

  1. 吊るし輪郭含めてページの表示必要な全ての輪郭知番一括取得するdg_fnd()
  2. 輪郭隠しにない輪郭情報一括取得するdg_oln()
  3. 自我隠しにない自我情報一括取得するdg_ego()

この新方式により,求頼最大でも3回み,KNEST 隠し十分に活用出来るようになった。同期隠しばら成しく,基礎として理想的だ。あとは必要に応じて HTML 隠しなどで補完すれば十分だろう。


upub導入した7月から微妙な応答速度低下気になるようになり,検索演心からのクロール頻度評価低下といった悪影響もあったため,輪郭情報取得改良高速化特効薬としても新生全知検索整備最優先当努だった。

最悪見込み違いという不安なくはなく,これだけ大胆な改良だったので不具合多発懸念大きかったが,速度安定性申し分ない結果となった。Cμ 文字列処理改良KNEST 隠し実装前後景時印導入といったこれまでの高速化施策しっかり活かせるようになったのも嬉しい

検索群類導入

4月7日10歩から検討していた検索属性」もここで「検索群類」として導入成功し異なる条件輪郭一覧結合出来るようになった

今後の検索結果改良大きな足場出来た

出場交度整理

最初に着手した b_bg_his の削除もここで本番環境適用され上描き履歴完全に廃止となった。


思わぬ収穫として,交度整理大きな進展もあった。

輪郭情報取得改良一見単純なようで,実際にやってみる意外に複雑な交度必要だった当初dg_fnd()SQL 周り最難関だと思い込んでいたため,6日の開発での解決時には一山越えた思ったが,その後のテンプレート処理の方が大変だった

この誤算で,長いこと放置していたテンプレート周りの乱雑な交度整理せざるをえなくなり,結果として自分でも驚くほど整理整頓出来てしまった

{共通定表式}{副求頼}{with}{SQL}=}(4)
{希哲16年7月15日の開発}{希哲16年7月15日の進捗}{希哲16年7月13日の開発}{把握しておいた}{わずかに}{反対の結果}{問題がありそう}{残しておいた}{改善しなかった}{こねくり回す}...=}(70)

{希哲16年7月15日12歩 K#F85E/E74C-70FE}

{ALTER TABLE}{定表名}{変更}{SQL}=}(4)
{SQL}

{}