{希哲17年1月28日の開発}{希哲17年1月28日の進捗}{希哲17年1月27日の開発}{希哲17年1月28日}{位置固定表示}{応用出来そう}{画面左下}{指定要素}{@msg.shw_cmn()}{くっつけて}...=}(191)

{希哲17年1月28日14歩 K#F85E/E74C-9326}

=}
{希哲16年9月26日}{希哲16年9月26日の副日記}{奇数ページ}{付けていなかった}{機能を整えた}{動的挿入}{発生時}{かくかくする}{溶明させる}{opacity: 0.7}...=}(81)

{希哲16年9月26日の開発 K#F85E/E74C-F544}

新生全知検索整備輪郭一覧動的更新対応

輪郭一覧動的更新対応については一段落

全知検索窓からの検索新規描出更新輪結輪郭一覧動的に更新出来るようになった。これまで通り握接出来る請い手にとっても捌き手にとっても負荷軽減になり,全知検索感触非常に良くなったSafari ではページ遷移発生時動き付け止まるため余計かくかくした感触だったが,これも解消した

デライトでは相振りとしての可使性ウェブサイトとしての可接性両立させた HPA(hybrid paging application)目指してきたが,自動ページ展開機能続いてこれで概ね理想に近いになった。第二次用合い改良新生全知検索整備交差点でもあり,感慨深かった

更新時動き付け多少工夫が必要だった最初は,更新前輪郭一覧完全に溶暗させ,更新後輪郭一覧溶明させるという動き付け試したが,ちかちかして良くなかったopacity: 0.7 まで少し溶暗させて置換してから溶明させるようにしたら良い感じになった。新規描出輪郭一覧上部移動する時はスムーススクロール鬱陶しいのでこの時だけ無効化するようにした。これで概ね満足出来た

ここで広告動的挿入必要になったため機能を整えた。これまで自動ページ展開部分には広告付けていなかったが,これを機に奇数ページ広告表示されるようにした。

{希哲16年9月22日}{希哲16年9月22日の副日記}{解決している}{設けた}{直接指定}{最近の出振るい}{下がった}{急いでいた}{発生しやすい}{適った}...=}(164)

{希哲16年9月22日の開発 K#F85E/E74C-FB21}

新生全知検索整備ページ付け求頼改良サイトマップ改良不具合修正など。

サイトマップ改良急進展

特に長いこと課題だったサイトマップ改良急進展した。

これまでサイトマップ全知検索ページャー同様,一定輪数LIMITOFFSET区切ったページ返していたOFFSET多くなる遅くなるため,最大でも最新10,000輪100輪×100ページ限度だった。upub 導入後更に低速化したため,9,000輪まで減らしていたが,それでも後半になると応答時間10秒以上になることがあった。

今回のページ付け求頼改良時印使ったページ付け移行しようとしていたため,これをサイトマップにも応用出来るのではないかと考えていたが,サイトマップ場合サイトマップインデックスサイトマップ URL一覧生成する必要があり,この効率性問題だった。HTML 隠し利用考えたが,タイミング難しく,大袈裟過ぎる気がしていた

サイトマップ場合各ページ輪数揃っている必要はないのだから,一定期間区切ってしまえばいいのではないか,ということに気付いてからは速かった

まず,デライト上最古の時印2012-02-10 19:09:33から現在時刻までを30日って必要なページ数割り出し,サイトマップインデックス従来通り形式/see?pg=[n]生成するdg_see() ではページ番号から期間計算してその範囲内上限輪数までの最新輪郭情報返す上限輪数とりあえず10,000輪にしておいた。数値様子を見ながら調整していく

インターフェイスそのまま利用したため修正最小限み,互換性維持出来たが,元々 dg_see()余計な多い問題があったのでそのあたり最適化しておいた。

実作業出振るい手定めまで正味3時間ほどで済み結果としてサイトマップ速度ページ数対応期間の長さはるかに向上した現在時刻基準なので,上限輪数から漏れた分待っていれば載ることになる。ここまでページ数が多いサイトでは網羅性効率性完全に両立させることは不可能なので,ここが良い落とし所だろう。デライト特有の要求適ったサイトマップ設計という,大きな問題また一つ解決した

輪数取得改良前後景時印導入などを経てサイトマップ高負荷求頼発生しやすい最後の箇所になっていたため,これでデライト安定稼動における不安要素払拭出来たページ付け求頼改良急いでいた理由でもあったが,最近の出振るいで,全知検索でもページ番号直接指定上限設けたため,高負荷求頼問題一応解決している。これでページ付け求頼改良優先順位少し下がった

{知番}{希哲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()
読み込み中...
{希哲16年7月}{希哲16年6月25日}{希哲16年6月}{振り返り日記}{日記}{焦る理由}{良い結果}{組計の乱れ}{歩を進めていく}{利楽して}...=}(75)

{希哲16年6月25日の日記 K#F85E/E74C-328D}

{完全に}

{}