{開発}{開発記録}{最大}{}{}{デライト}{希哲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年6月}{希哲16年6月30日}{振り返り日記}{終わってみれば}{従ってきた}{増え始める}{残してある}(69)

{希哲16年6月30日の日記 K#F85E/E74C-5CF8}

{『希哲日記』}{日記}{希哲15年4月の月記}{希哲15年4月17日}{短期集中生活}{気の緩み}{半休}{不安要素}{急激}{メリハリ}(12)
{『希哲日記』}{写真}{日記}{}{}{}{正午}{デライトの成功}{希哲館事業}{希哲15年4月の月記}(58)

{希哲15年4月15日の日記 K#F85E/E74C-F52C}

10時45分頃,第二子無事出産したとから伝えられた。産まれたのは7時ちょうどで,母子ともに元気だそうだ。

とも連絡を取り,姉妹写真を送った。父もまだ元気そうで少し安心した。


正午頃,中途半端保険はかけず,5月1日までにデライト収益目標を達成するという前提全力を尽くすことを決意した。

最近,失敗した場合のことを考え過ぎていた。仮に失敗しても,せいぜいすり傷が出来るくらいのことだ。個人的にも希哲館事業にとっても別に死活問題ではない。心配から来る雑念足を引っ張られていては,成功するものも成功しない。

こんな心境の変化があったが,昨日の現状整理,姉の吉報と来て,当面の不安要素が無くなったせいかもしれない。


実は,姉の子が生まれたという頃,不思議な夢で目が覚めていた。完成したのか建設中なのか,希哲館本館らしき建物の中に自分が居るだった。不思議だったのは,この種の夢を見ることが滅多にないからだ。それも,ちょっとした良い夢ではない。希哲館事業にとっては最大級吉夢だ。

収益目標達成,すなわちデライトの成功まで残り半月,あとは高速化全力推し進めるのみという所で,何かと幸先が良い。今そんな幸運を感じていられること自体も奇跡のように思える。

{不安要素}

{}