WordPressで記事が多くなると遅くなるサイドバーウィジェット

前回の記事でWordPressには記事件数の増加に伴い重くなるSQLがわかりました。

https://firegoby.jp/archives/2159

しかしMySQLは非常に高速なので、遅いSQLが一回ぐらい入ったからと言って、特に遅いと感じることはありませんでした。

じゃあ、遅いSQLが何回も入ったらどうなるの?ということで、今回はサイドバーウィジェットのSQLを一つずつ検証します。

いきなり結論

遅いサイドバーウィジェットランキングは以下のとおりです。

環境は前回の記事と同じです。(ダミーの記事を約24,000件投稿しています。)

秒数はSQLの実行時間ですが、環境によってかわるので比較用の目安程度で考えてください。
また、複数のSQLが発行されるサイドバーウィジェットでは、合計値を表示しています。

順位 ウィジェット名 秒数
1位 最近の投稿 約0.49秒
2位 カレンダー 約0.31秒
3位 アーカイブ 約0.02秒

注意: カレンダーが遅いのはテスト方法に問題があるためと思われますので、以下を読んでください。

最近の投稿はなぜ遅いか?

前回の記事でも説明しましたが、WordPress上では記事を最新順にソートするSQLは、インデックスを活用できていないために、実際に必要なデータの件数がわずかでも全てのレコードをスキャンしています。

これは、カテゴリーアーカイブなどのようにスキャン対象が別のwhere句で絞りこまれていれば、少しはましになりますが、トップページや「最近の投稿」など「カテゴリーに関係なくとにかく最新の記事をよこせ」といったSQLでは、記事の件数が増えるに従って確実に遅くなっていきます。

カレンダー

今回のテストでカレンダーが遅かったのは、テスト環境の構築によるものだと思います。

というのは、24,000件の投稿データはループ処理でまとめて投稿しましたので、すべての記事が同じ日付で投稿されています。

したがって、通常の1日数件程度の投稿であれば1/1000秒台のスピードで処理できると思いますが、もし何らかの方法で大量の記事を投稿する場合には、パフォーマンスが問題になると思います。

アーカイブ

アーカイブは、投稿月ごとに記事をグループ分けするSQLが記述されており、全てのレコードをスキャンしていました。

そのため、他のウィジェットと比べると、遅い部類に入るサイドバーウィジェットです。

その他のサイドバーウィジェット

カテゴリーやタグクラウドのサイドバーウィジェットはこれらについで遅いSQLでしたが、0.002秒程度のものでした。
ただし、この二つはUsing filesortUsing Temporaryが出てますのでカテゴリー(タグ)が増加すると遅くなる可能があります。

これら以外のサイドバーウィジェットは、さらに一桁下がって0.0002秒とかそんなオーダーでした。
SQLだけを見ればパフォーマンスには影響ないと言えます。

最後に

サイドバーウィジェットが実行するSQLをダンプしたデータを置いておきます。

配列内には、関数の呼び出し元や、SQLのベンチマークの結果などが含まれます。

ダンプデータ