(さいだい)
この際,譜類添付機能の仕様を完全に固め,新生全知検索整備に戻る前に実装してしまうことにした。仕様・方針をまとめて終了。
まず,最初は上信対応形式を JPEG,PNG,GIF,WebP のみとし,サイズ上限は5MB,最大長辺は1920px,WebP 以外は一律 WebP 変換する。このあたりの仕様はとりあえず実績のある kn upl
に合わせておくことにした。
希哲15年9月3日の開発では WebP 統一は時期尚早として見送っているが,同年12月3日の開発から写真上信のため WebP 統一を決め,実践を通して全く問題ないことが分かっている。
予定通り,利用者毎の容量上限は定めず,状況次第で一時停止出来るようにしておく。
新生全知検索整備,ページ付け求頼改良,サイトマップ改良,不具合修正など。
これまでサイトマップは全知検索ページャー同様,一定輪数を 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時間ほどで済み,結果として,サイトマップの速度・ページ数・対応期間の長さがはるかに向上した。現在時刻が基準なので,上限輪数から漏れた分も待っていれば載ることになる。ここまでページ数が多いサイトでは網羅性と効率性を完全に両立させることは不可能なので,ここが良い落とし所だろう。デライト特有の要求に適ったサイトマップ設計という,大きな問題がまた一つ解決した。
輪数取得改良,前後景時印の導入などを経て,サイトマップは高負荷求頼が発生しやすい最後の箇所になっていたため,これでデライトの安定稼動における不安要素が払拭出来た。ページ付け求頼改良を急いでいた理由でもあったが,最近の出振るいで,全知検索でもページ番号の直接指定に上限を設けたため,高負荷求頼の問題は一応解決している。これでページ付け求頼改良の優先順位が少し下がった。
最初の中間出振るいに成功。これにより,全知検索の応答速度,柔軟性,交度品質が大きく向上した。出振るい作業も円滑に進み,手溢れも無く,全体として大成功だった。
まず,期待通り,輪郭情報取得方式の改良により応答速度が大きく向上した。体感的にも,この種のサービスとしては並という程度から,はっきり速いと言える程度になり,快適度が数段上がった感覚がある。
これまでのデライト高速化施策の中でも最大級の効果を感じるが,これはボトルネック解消によるところが大きい。6月の Cμ 文字列処理改良あたりから,領下手定め環境での高速化効果の大きさに比べて本番環境での効果がかなり小さいと感じるようになっていた。考えられるボトルネックは,相振り・出場間の通信回数が多過ぎる輪郭情報取得処理だった。
これまで,ページに表示される輪郭情報の取得は,相振りから大体次の流れで行っていた。
dg_oln()
)。dg_fnd()
か,吊るし輪郭の初期状態は dg_fg()
,dg_bg()
)。この旧方式では,KNEST 隠しも一部でしか活用出来ておらず,中景輪数に応じて求頼が増え過ぎる問題があった。1ページあたり最大45回の求頼が発生する可能性があったことになり,当然,相振り・出場間の通信コストがそのまま応答速度低下に繋がっていた。
KNEST 隠し実装を一段落させた6月30日の開発でまとめた方針に基き,これを次のように改良した。
dg_fnd()
)。dg_oln()
)。dg_ego()
)。この新方式により,求頼は最大でも3回で済み,KNEST 隠しも十分に活用出来るようになった。同期と隠しのばら成しも良く,基礎として理想的だ。あとは必要に応じて HTML 隠しなどで補完すれば十分だろう。
upub
を導入した7月から微妙な応答速度低下が気になるようになり,検索演心からのクロール頻度や評価の低下といった悪影響もあったため,輪郭情報取得改良は高速化の特効薬としても新生全知検索整備の最優先当努だった。
最悪見込み違いという不安もなくはなく,これだけ大胆な改良だったので不具合多発の懸念も大きかったが,速度も安定性も申し分ない結果となった。Cμ 文字列処理改良,KNEST 隠し実装,前後景時印の導入といったこれまでの高速化施策がしっかり活かせるようになったのも嬉しい。
4月7日10歩から検討していた「検索属性」もここで「検索群類」として導入に成功し,異なる条件の輪郭一覧を結合出来るようになった。
最初に着手した b_bg_his
の削除もここで本番環境に適用され,上描き履歴は完全に廃止となった。
輪郭情報取得改良は一見単純なようで,実際にやってみると意外に複雑な交度が必要だった。当初,dg_fnd()
の SQL 周りが最難関だと思い込んでいたため,6日の開発での解決時には一山越えたと思ったが,その後のテンプレート処理の方が大変だった。
この誤算で,長いこと放置していたテンプレート周りの乱雑な交度も整理せざるをえなくなり,結果として自分でも驚くほど整理整頓出来てしまった。