サイトマップ生成プラグイン「XML Sitemap & Google News」×キャッシュプリロードの落とし穴【WordPress】

あまりに情報需要が少なそうなネタなので、自分用メモ。

記事数が多いサイトだと、サイトマップ生成プラグイン「XML Sitemap & Google News」の設定×キャッシュ系プラグインの設定しだいでは、サーバー高負荷の原因となるケースがある、というお話。

キャッシュプラグインが入っている前提だから、当然、普段のサイトマップ要求はキャッシュで捌ける。つまり、通常のシナリオであればサーバー負荷的な問題はない。

しかし、例えば W3TC のような一部のキャッシュプラグインでは、（ユーザー要求の前に予めキャッシュを温めておく）キャッシュプリロード処理の各サイクル毎に、非キャッシュなサイトマップを要求するシナリオがあり、この挙動が W3TC のプリロード設定しだいでは問題を引き起こすことがある。

これは例えば、W3TC の設定が「1分おきに20ページずつプリロード」だったりすると、サイトマップ生成処理が重い場合、毎分、サーバー負荷が悪化してしまう、といった具合だ。

さらに悪いことに、W3TC にはプリロード時のサイトマップ要求やキャッシュ生成要求のスロットリング機能が標準では備わっていない（※）「サーバーに負荷をかけやすい仕様」であることも、問題を顕在化させやすい。

（※ スロットリングする方法がないとは言っていない）

で、ここからがようやく本題。

大規模サイトで、「XML Sitemap & Google News」×キャッシュプリロードのこのような相性問題・パフォーマンス問題を解決するには、

• サイトマップ生成の高速・軽量化
• キャッシュプリロード処理の洗練

が有効となってくる。

WEB の基本は「極力キャッシュで返す。キャッシュミス時でも極力サーバーリソースは消費しない」であるから、サイトマップ生成処理自体の高速化は理に適った、優先すべき対策だ。

実は「XML Sitemap & Google News」では、「XML サイトマップ」設定の「投稿タイプ」タブの設定でサイトマップ生成速度をかなり高速化できる。

軽量化のポイントとなる設定は以下。

＜投稿＞

• 分割単位：なし
• Update the Last Modified date on each new comment.：OFF
• image タグを付加：なし

＜固定ページ＞

• Update the Last Modified date on each new comment.：OFF
• image タグを付加：なし

たったこれだけで、1記事毎に詳細情報取得処理が走るいわゆる N+1 問題を緩和できるほか、とくに長期運営サイトでは WordPress データベースの標準インデックスを活かしづらいクエリ発行も大幅に削減できる。

対策をどれか1つの設定に絞りたいなら「サイトマップを年・月・週で分割しない」がオススメ。クエリの質の改善だけでなく、そもそもサイトマップの本数が減るので、「クエリの質×回数」の掛け算で高速・軽量化が期待できる。

もう1つの W3TC 側のキャッシュ生成の処理密度を下げる対策だが、こちらは必要なら W3TC のキャッシュプリロード処理のスロットリング用に簡単なプラグインを開発してしまうのが大変有効。加えて、環境・リソースに合わせたプリロード設定の調整も肝になる。

このあたりの具体的な話は、PHP-FPM の request_terminate_timeout、request_terminate_timeout_track_finished とか、そもそも PHP のコンパイルオプション自体がスリープ時間を max_execution_time に含めない構成になっているか等々、ベストプラクティスのアチーブにはややこしい環境差が絡むので今回は割愛する。

この記事をここまで読み切れた方なら、今どき AI の力を借りれば自分にあったコンフィギュレーションを見つけられるだろうしね。

以上、お役に立てれば幸いです。