WordPressサイトでwp_optionsのautoloadが遅い
WordPressのパフォーマンスが低下
WordPressのパフォーマンスが低下し、1秒間に1リクエスト程度しか処理できなくなりました。
何がボトルネックになっているか調べた結果です。
WordPressパフォーマンス低下の原因
原因は、WordPress DB、wp_options Tableのautoload = 'yes'レコードに、
大きなサイズのデータがあったことです。
SELECT option_name, LENGTH(option_value) as optlen
FROM wp_options
WHERE autoload = 'yes'
ORDER BY optlen DESC
LIMIT 10;
+--------------------------------+---------+
| option_name | optlen |
+--------------------------------+---------+
| XXXitem | 2647013 | ← コレ
| XXXsession | 97179 | ← コレ
| XXXXX | 41519 |
| redux_builder_amp | 35331 |
| rewrite_rules | 13516 |
| _site_transient_update_plugins | 6471 |
| wp_user_roles | 5002 |
| bcn_options | 2984 |
| ampforwp_exclude_post | 2966 |
| _site_transient_update_core | 2747 |
+--------------------------------+---------+
解決方法
wp_optionsの原因となるレコードを
-
削除する
-
autoloadを’no’にする
のどちらかです。
今回はUPDATEでautoloadを’no’にしました。
UPDATE wp_options SET autoload='no' where option_name = 'XXXitem';
UPDATE wp_options SET autoload='no' where option_name = 'XXXsession';
その結果、1秒間に1リクエストから15リクエストを処理できるようになりました。
後に不要とわかったのでDELETE文で削除しました。
DELETE FROM wp_options WHERE option_name = 'XXXitem' ;
DELETE FROM wp_options WHERE option_name = 'XXXsession' ;
なぜ遅くなるか
WordPressのwp_options一括読み込みのために発生します。
-
WordPressはアクセスがあると、wp_optionsテーブル中のautoload=‘yes’のレコードをすべてSELECTし、キャッシュする。
-
wp_optionsの巨大データはPHP unserializeされるタイプだった。
巨大データがアクセスのたびにunserializeされていた。
本来、WordPressのwp_optionsテーブルには巨大サイズデータを登録するテーブルではありませんが、 いつの間にか登録されていました。
なぜ巨大データがautoload=‘yes’で登録されていたのか
過去に入れていたWordPressのプラグインが登録したデータのようです。
プラグインアンインストール時に消してくれなかったようです。
wp_optionsテーブルには、他にもたくさんの不要そうなレコードが登録されていました。
本当に不要なレコードであれば削除すべきですね。
その他
WordPressのwp_optionsにデータを登録する場合は、
update_option()関数の$autoload引数の指定をチェックしましょう。
必要性の低いものをautoload=‘yes’にすると、パフォーマンス低下につながります。