uniform resource locator
{希哲17年1月11日3歩 K#F85E/E74C-6CC5}
宇田川浩行<iframe>
}{渡括記法}(24){希哲17年1月8日8歩 K#F85E/E74C-408C}
宇田川浩行src
属性}{<script>
}{希哲16年12月19日の副日記}{付かない}(192){希哲16年12月19日の開発 K#F85E/E74C-E210}
宇田川浩行自我ページと風船輪郭
長いこと課題だった自我ページと風船輪郭について良い閃きがあり,急速に実装方針がまとまった。
現状,自我ページは URL のみ正規化している(/KNo.XXXX
)が内容は単なる自我知番での検索結果であり,プロフィールページとしては貧弱過ぎる。自我輪郭などの案はあったが,既存機能や領当てとの整合性をとるのが難しく,自我ページとしてはなかなかイメージがまとまらなかった。かなり難航しそうだったため,新生デライトの要件にも入れなかった。
最近の大輪郭整備で必要性を強く感じるようになっていたこともあり,もう少し現実的に,低コストで実現出来る案でまとめてみることにした。
まず,他自我内検索の用合いを既存の自自我内検索と整合させるため,以下のように,自我アイコンを並べるか重ねるかして,& ボタンで段階的な切り替えが出来るようにする。さらに,自我アイコンの下に「○○さん K#XXXX の描き出しです。」と表示する。
これで,全知検索の機能性はそのままに,プロフィールページに最低限必要なアイコンと名前の表示が出来る。自我アイコンの複数表示自体はかなり以前から他自我内検索用合いの案としてあったが,これに名前を添えてプロフィールページの見出しを兼ねさせるというアイデアが新しかった。
大した作業ではなく,新生デライトの完成の遅れも今更なので,これは新生デライトの要件に追加することにした。
height
属性}{width
属性}{希哲16年12月21日の進捗時限}(26){希哲16年12月21日5歩 K#F85E/E74C-B32F}
宇田川浩行{希哲16年12月18日の開発 K#F85E/E74C-8AE4}
宇田川浩行新生全知検索整備・中間出振るい
領下手定め環境で概ね問題なさそうだったため,新生全知検索整備の中間出振るいに踏み切った。首尾良く完了し,大成功だった。これにより後縁も最新の状態で同期され,自由自在な開発体制を取り戻した。
21時30分出振るい作業開始。断帯は21時30分から約5分。23時頃までには一通り点検・不具合修正を終えた。
その後,動作は極めて安定している。dg_fnd()
への輪数取得処理組み込みは今回初出振るいとなるが,高速化効果は,毎回輪数計算が必要になる場合の検索で数十ms(求頼1回分)の短縮なので体感速度向上はあまり期待していなかった。しかし,意外と検索時の軽快感が増している気がする。最初はプラセボ効果に近い開発者心理かと思ったが,自分の全知検索歴と検索頻度を考えれば感じ取れてもおかしくはない。嬉しい誤算だった。
輪符と知番の輪結改良
安心して後縁に手を入れられるようになったので,手始めに,輪符が生成する輪結で,第零番節付き知番がそのまま輪結先などに反映されてしまう問題を修正した。
これにより,輪符の知番が K#9-XXXX/A-YYYY
と記述されていても,輪結先は第零番節の削除をした /?fg=KNo.XXXX/YYYY
や /KNo.XXXX/YYYY
となる。第二次知番改良を経て司組が生成する知番はこれで統一するようになったが,デラングでは大量にある第零番節付き輪符が第零番節付き輪結を生成していたため,クロール効率への悪影響が懸念された。出与え属性を通して輪郭小窓の知番表示にも反映されていたため,用合い上の問題もなくはなかった。
とりあえずは量が多い基本形の輪符と重い強調輪符でのみの対応。
{希哲16年9月22日の開発 K#F85E/E74C-FB21}
宇田川浩行新生全知検索整備,ページ付け求頼改良,サイトマップ改良,不具合修正など。
サイトマップ改良の急進展
これまでサイトマップは全知検索ページャー同様,一定輪数を LIMIT
句・OFFSET
句で区切ったページを返していた。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月22日7歩 K#F85E/E74C-E687}
宇田川浩行K#
}{希哲16年7月30日}{知番接頭子}{希哲16年7月30日の開発}{希哲16年7月30日の進捗}{目に触れる}{原則として}{多々あった}(32){希哲16年7月30日3歩 K#F85E/E74C-433A}
宇田川浩行{希哲16年7月28日16歩 K#F85E/E74C-F746}
宇田川浩行最近,実用上深刻な問題ではないものの体感的に壊衝が増えていたが,握接録をよく観察してみると,ほとんど特定パターンの URL で発生していることが分かった。大きな原因は次の2つだった。
DG_T::cnt_fnd()
が番無し輪郭の旧い記法K#A-XXXX
などでの握接時に壊衝していた。- 存在しないページへの握接時に返す
404 Not Found
用のページ定義が過去の整理で消えていたせいで,ここでも壊衝していた。
これらの URL にボットが握接したことによる壊衝が多発していた。
一応の修正・出振るい済み。まだ小さな問題はあるが,だいぶ安定しただろう。KNEST 隠し実装以後の排他制御の問題だとすると厄介だなと思っていたので一安心。
壊衝していたということは KNEST 隠しも十分活かせていなかったということで,最近感じていた体感速度低下の一因だったか。upub
の導入ばかりが原因だと思い込んでいた。
lightgray
}{外部輪結アイコン}{希哲16年7月26日の進捗時限}{silver
}(24)