{希哲16年9月18日}{希哲16年7月}{希哲16年6月}{希哲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日の開発での解決時には一山越えた思ったが,その後のテンプレート処理の方が大変だった

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

{希哲16年8月21日}{希哲16年8月20日}{希哲16年8月の開発}{_dg}{調査する}{特有の問題}{根本的な解決}{無理そう}{負荷抑制}{選択肢が増える}...=}(102)

{希哲16年8月20日の開発 K#F85E/E74C-1175}

応答速度異常に遅い輪郭についての不具合調査から求頼改良出場改良アイデアまとまり,一気に実装した

_dg_dg_oln結合しないと揃え出来ず揃え極端に遅くなる場合があることは認識していたが,時印追加することは正規化観点から避けてきた

公開設定機能導入必要性が低くなった揃え用時印廃案にすることを最近考えていたが,これに近い役割持たせた ts_fgts_bg追加することを思い付き,急速にまとまった単なる複製ならやはり避けたかったが,より抽象的な時印_dg持っていることは不自然ではなく,同期引き入れ再描出処理行うだけでいい。

手定めしてみると,低負荷求頼では索引使われず有意差見られなかったものの,高負荷求頼では数倍から十倍程度までの高速化見られた求頼最適化選択肢が増えることでサービス全体負荷抑制見込める

領下での実装手定め終えたが,稼動させながらの _dg修正無理そうなので明日早朝出振るいすることにした。


これにより応答速度異常に遅い輪郭についても改善見られたが,異常であることは変わらず根本的な解決にはならなかった。

当初輪括膨大な輪郭特有の問題だろうと思っていたが,一見何でもなさそうな輪郭でも発生している

これは別途調査することにした。


ここで,検討していた揃え用時印ts)は正式に廃案とすることにした。

簡単な時印更新可能になり,公開設定機能目立たせない再描出可能になったので必要性感じなくなった。となると実装用合い複雑化懸念大き過ぎる

{希哲16年8月中旬}{希哲16年8月上旬}{希哲16年7月26日}{振り返り日記}{日記}{温存していた}{もう一頑張り}{やや遅れている}{ここまでの}{結果を待てる}...=}(76)

{希哲16年7月26日の日記 K#F85E/E74C-8272}

{希哲16年5月23日}{抜控}{}{出振るい}{低下する}{発生していない}{心当たりがない}{一番気になった}{新規描出下書き抜控}{判別用}...=}(225)

{希哲16年5月23日の開発 K#F85E/E74C-8D2F}

輪郭選り手抜控機能整備概ね終えようやく出振るい出来た追い追い修正していけばいい程度の軽微な不具合はいくつか見つかったが,抜控機能整備についてはここで一段落とすることにした。

この出振るいにより,中途半端な実装だった輪郭選り手抜控機能一通りの機能揃った下書き抜控一覧使えるようになり,抜控把握容易になった予てから欲しかった新規描出フォーム消去復元ボタン抜控削除のため追加した18日の開発実装した描写拡縮ボタン使えるようになった。また,周辺の交度整理大きく進み,理腑としての意義大きかった

利便性信頼性向上はもちろんのこと,昨年から中途半端な状態引きずってきた当努片付いたことによる精神衛生上効果大きい昨年来他の当努本格的に着手していないか,着手して間もないので,ここから思考整理しやすくなる


抜控機能整備長引いた最大の原因は,他にやりたいこと多過ぎたことだが,これ自体も決して簡単な作業ではなかった。ただ,この間設計方針変わったり深刻な不具合気付いたりしたので,時間をかけたことで円滑に片付いたもある。

再描出知番でいいとして,新規描出をどうするか,というのは難しい問題一つだった。昨年7月28日6歩から検索語含めるようにして悪くなかったので,基本的にこれを踏襲することにした。ただし,全知検索窓から未送信検索語まで取っていたため,これを書き換える意図せず他の抜控上書きしたり消去してしまう可能性があった4月28日20歩書いた消失不具合原因だろう)。これは求頼文字列から取ることで回避した

下書き抜控一覧についても,表示条件領当てなど色々考えること多かった検討の結果再描出下書きは,検索語無し場合上部メニュー同様のみ輪郭一覧表示画面撮り新規描出下書きは,他の抜控がある場合のみ新規描出フォーム上に常に表示させることにした画面撮り邪魔になり過ぎない程度に気付きやすい。また,4月10日の開発決めた通り一覧省略などせずにそのまま表示することにした。描写部のように高さ固定することも考えたが,やはり,用合いの複雑化抜控溜め込み過ぎる懸念があるため見送った抜控溜め込み性能低下消失リスク増大(あるいはそれを補う作業コスト増大繋がる目障りになったら消化するようにしてもらいたい。

一番難しかったのは鍵仕様設計だった。一応鍵仕様変更時の更新方法考えていたが,手間考えるころころ変えるわけにもいかないので,長期的視野に立って設計する必要があった。これもなんとか落とし所見つかった一時仕様変更日時含めることを考えていたが,これは複雑化招くだけなので廃案とし,Aejs_DG_rev判別用文字列入れておくことにした。新規描出下書き抜控には自我知番含め自我切り替えにも対応した

その他,これまで描写のみ保存していたのを知名にも対応する消去ボタン復元ボタン実装する,などこまごまとした問題片付ける必要があった


出振るい後軽微な不具合がいくつか見つかったが,一番気になったのが,鍵仕様更新処理失敗だった。領下十分な手定めをしたつもりだが,本番環境では一部1回処理更新出来なかった結果的に3回実行する必要があった開発者通類localStorage内容見ても交度見返しても心当たりがない

少し迷ったが,時間が経つにつれ重要性急速に低下する部分なので,調査打ち切ることにした。最も使用頻度高い常連用者達が出振るい後普通に使えていることから,深刻な問題発生していない判断した今後同様処理書く際の注意点として記憶しておく。

=}
{懸念}

{}