時代が,10年以上前に実装した知番の100歩手前くらいに来たかな……。
Google のクロール統計で平均応答時間が異常な値になっている問題についての調査で終了。
Googlebot が稼動している捌き手の問題であることが判明したため,しばらく様子見することにした。
1月上旬から平均応答時間とクロール頻度が不自然に悪化した状態が続いていた。決して速くない自宅回線からでも大半のページが300ms前後で応答しているにもかかわらず,クロール統計ではほとんど600ms前後で高止まりしている。
1月上旬といえばデライト高速化が快調に進み,理論上も体感上も満足出来るようになってきた頃なので,明らかにおかしかった。Googlebot が握接しているページに Googlebot の用影で握接しても遅いということはなく,Applebot や bingbot はむしろ活発化している。
こうなると Google 側の問題か,と考え始めた。Googlebot は主に米国内から握接しているので,日本国内からの握接と多少の差があってもおかしくはない。ただ,これ以前にここまでの差を感じたことがなく,クロール統計上で1月上旬から悪化しているので,Google 側で何かがあったことになる。
ちょうど Alphabet が経営的にごたごたしていた時期でもあり,保守人員が不足しているとか設備を縮小したということはありそうだ。条件は不明ながら米国外の捌き手を使うこともあるそうなので,これまで近場の捌き手を使っていたのにデライトが高速化し過ぎて米国内からの握接で十分と判断された,なんて皮肉な話も考えられなくはない。
ここまで考えたところで ping
に200ms以上かかる Googlebot の IP アドレスを見つけ,原因は判明した。
こちらではどうしようもないことだが,不気味な現象だったので気分的にはすっきりした。むしろ,問題が解消した時が楽しみになってきた。
作業方針検討(4歩),閲覧専用模動実装検討(5歩),デラング整備・埋め込み記法処理改良(8歩〜13歩)。
これまで,埋め込み記法処理の中でも oEmbed を利用したものについては,Dex 内で埋め込み交度の取得を行い直接描写 HTML に埋め込んで返していたが,埋め込み交度の取得処理を専用 API /mbd
に委ね,前縁 Aejs から利用することにした。結果として,応答速度改善に成功した。
埋め込み記法(+[URL]
)の URL が oEmbed を必要とする場合,Dex では適当な分類名を付与した <div>
に出与え属性で URL を埋め込んで描写 HTMLを返す。Aejs ではそれを検知し,URL を /mbd
に転送する。/mbd
は URL に対応したサービスの埋め込み交度を oEmbed で取得して返す,という流れになる。過剰な立求を抑止するため,Aejs には簡易的な隠しも持たせておいた。
そもそものきっかけは,先日の SlideShare 対応だった。oEmbed が必要になったので,埋め込みツイートで使っていた Dex 内の oEmbed 埋め込み方法を取り急ぎ使った。ただ,記法処理範枠に同期通信処理を組み込むというのは正気の沙汰ではない。なんでこんな実装になっているのか,引っかかりはあった。
KNEST 隠しを使った SSR 的なことを考えていたことはあるので,その辺の都合だったのだろうと思ったが,現状,そこまで最適化する必要も時間も無い。出来たとして,隠しを有効利用出来る握接パターンは限られている。いずれにせよ,この種の埋め込み記法の利用が増えてくれば破綻は目に見えている。ということで,いったん,埋め込み処理は前縁に移すことにした。
9日の SlideShare 対応後,意外にもすぐに若干の応答速度低下を感じるようになり,作業の優先順位が上がった。スライドの埋め込み自体はデライト公式での紹介輪郭でしか使われておらず,因果関係は不明だったものの,時期があまりにも一致していた。Google のクロール統計でも,9日以後はそれ以前と比べて100ms以上の平均応答時間増加が連日見られ,体感とも一致していた。
ざっと Aejs で oEmbed を利用する交度を書いて実行してみると,CORS の違了が発生し,一気に記憶が蘇ってきた。
元々前縁でやろうとしていたのを,CORS 問題が面倒で後縁完結にしたのだった。よほど高尚な理由がないとこの実装はありえないだろうと深読みしていたが,なるほど,単なる一時凌ぎという線があった。当時の記録も残っていた。
仕方ないので,当時面倒臭がってやらなかった専用 API を作ることにし,/mbd
を追加した。Aejs には埋め込み記法処理を集約する @mbd
を追加した。
中継サービスを利用するのが一番簡単な方法だが,信頼性や使い勝手などで不確実性が高い。
出振るい後,すぐに明らかな体感速度向上が見られた。もう少し様子見は必要だが,見込みは正しかったか。だとしても,応答速度低下の原因ははっきりしていない。原因究明にかけられる時間も無い。
一つの輪郭中の一つの oEmbed 通信がサービス全体の応答速度低下を招いたとは考えにくい。考えられるとすれば,握接集中で立求処理が詰まった,あたりか。SlideShare 対応によって気付かない内に何らかの問題を持ち込み,埋め込み記法処理改良によって解消したか,全く別の問題が偶然同時期に発生していただけ,という可能性もなくはない。
いずれにせよ,今回の埋め込み記法処理改良によってデライトの安定性・効率性が大きく向上したのは間違いない。従来の方式では,ページ内で oEmbed を利用する回数×通信時間の応答速度低下があった上に,描写 HTML のタグ削除をしている RSS でも無駄な通信が発生していた。
これは方式によらず発生しうる問題だが,下見機能などで頻繁に更新する場合,その都度 oEmbed 通信が発生していたことに気付き,@mbd
に客体変数を使った隠しを持たせておいた。役割分担が進んだことで今後はこうした最適化もやりやすくなる。/mbd
に隠しを持たせることも検討しておくことにした。
少し懸念していたのが埋め込み献典の描画速度だったが,これも全く気にならなかった。そもそもこの手の埋め込み献典の描画は遅いものなので,多少の変化では分からない。
希哲荘の給湯器は設置から17年以上は経っているであろう古いものなので,いつ壊れてもおかしくなかった。ここ5年ほどの間か,給湯温度がやや不安定になったり,風呂場のリモコンが効かなくなったり,全てのリモコンの画面が映らなくなったり,少しずつおかしくなっていた。昨年も交換をちょっと検討したが,すでに半導体不足で入手困難という時期だったため騙し騙し使ってきた。
明日業者に来てもらうことになったが,とりあえず,給湯器を使わずに凌ぐ方法を考えておいた。一番心配だったのが入浴だが,これは足湯バケツと電気ケトルを使った「バケツ浴」で何とかなりそうだ。
ネットで見かける投げ込みヒーターが使えるかもしれないと近くの家電量販店を回ってみたが,どうも当たり前に売っているものではないらしく,見つからなかった。ネットで買うのも安全性などが怪しい上に,どれも配達日が遅い。結局,必要なさそうだ。
しばらく給湯無しで生活する覚悟が出来,寝ようと思った26時頃,ランプが点いたまま全く反応しなくなっていたリモコン電源ボタンのランプが消えていることに気付いた。試しに押してみると,あっさり起動して湯が出るようになった。
いずれにせよ交換することになりそうだが,新しい給湯器が来るまで持ってくれることを願うばかりだ。
OFFSET
句}(211)デライト高速化における KNEST 隠し実装が一段落した。18日は作業方針検討のみで20日から,休日を除いてちょうど10日間での達成だった。夜に出振るい済み。
必要以上に固め過ぎるのも良くないため,隠し化は現時点で最低限必要な範囲に留めたが,期待以上の安定性で期待通りの高速化が得られた。次の施策も出来たので,まだまだ高速化出来る。KNEST 隠しは Dex に匹敵するデライトの武器になるだろう。
交度整理をしっかり進めたこともあり最初の輪数取得改良が想定以上に長引いたものの,ここで KNEST 隠し共通の問題がほとんど解決したため,自我隠し・輪郭隠しは半日ほどで終わった。この交度整理も収穫として大きかった。輪郭操作系の kn
の外充て函数を整備したことで関連交度も一気に整理された。
影響範囲と確率的に大きな問題はないだろうと見て,排他制御が甘い部分をあえて残して出振るいを急いだが,出振るい直後に壊衝が多発して少し焦った。すぐに論軸的な問題と気付き修正し,その後はむしろ想定以上に安定して動いている。この判断も結果として正解だった。
輪数隠しに関しては,第二次知番改良中に固まった「輪数取得改良」として,輪数取得の仕組みを全体的に改良した。
これまでデルンではいちいち厳密な輪数表示をしていたが,これが大きな低速化要因になっていた。デライト以前まで,count()
の遅さに対する認識が甘かった。デライト以後,そもそも出場における件数計算は原理的に遅いもの,と気付いてページ付け(OFFSET
句)に上限を設けるなどの対策はしていた(希哲13年10月14日の開発記録)が,輪数は一筋縄ではいかない部分があり放置してきた。
厳密な同期の必要性や隠し効率から,次のように整理することにした。
また,この過程で各輪郭操作での輪数更新が必要になったため,ほとんど未実装だった輪郭操作系の外充て函数を整備した。
自我隠しに関しては昨年4月に中途半端な実装をしていたため,これを整理した。輪郭隠しは,現時点で一覧部分には適用出来ないものの一応実装しておいた。
自我隠しが出来たことで自我情報を利用しやすくなったため,自我アイコンに ts_upd
を使った隠し破りを付けたかったが,自我情報の取得部分がまだ非効率なので見送った。
輪郭情報も求頼を分割し過ぎているので,これを統合することを考えているうちに,次の施策がまとまった。
輪郭一覧については,まず知番のみで中景輪を取得し,輪郭隠しと照合してから三景の輪郭情報を同時に取得することにした。これで輪郭隠しを効率的に利用出来,求頼を大幅に減らせる。予定していた検索属性もここで盛り込む。