ry0ta.ma2daさん、こんにちは。
状況から思い浮かぶのは、WordPressのcronの失敗、WordPressやテーマ・プラグインなどの更新情報を取得する際のネットワークの遅延あたりの可能性でしょうか。
といっても推測でしかないので、しっかり原因を究明しないといけません。
Debug Bar、Debug-Bar-Extenderなどのプラグインを使って、どこで処理に時間がかかっているかなどもう少し詰めてみる必要がありそうです。
jim912さん
アドバイスありがとうございます。
また質問させて頂きたいのですが、Debug Bar、Debug-Bar-Extenderをインストール、有効化したのですが、管理バーに「Debug」メニューが表示されません。
以下のサイトを参考に、wp-config.phpにも以下のコードを追加しています。
define('SAVEQUERIES', true);
define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', false);
・参考にしたサイト
http://dogmap.jp/wckobe2011/
http://www.warna.info/archives/1239/
利用中のWPは2つのプラグインに対応しているバージョンのはずなのですが、2プラグインのインストール、有効化、wp-config.phpにコード追加、以外に何か設定が必要かご存知でしょうか?
お手数ですが、よろしくお願いします。
ry0ta.ma2daさん
Debug Barのメニューですが、最新版と3.1系だと表示されないようです。
- WordPressを最新版にする
- Debug Barのソースを一部書き換える
のいずれかで対応してみてください。
jim912さん
情報ありがとうございます!
「2.Debug Barのソースを一部書き換える」で表示されました!
ただ、複数ページにアクセス・Debugで「Queries」を確認していますが、同じページで同じクエリでも、複数回アクセスしていると、時間がかかっていたクエリが次第に速くなったり、そもそも発行されなくなったりと結果がまちまちで、まだ遅延の箇所や傾向がつかめていません。
※100ミリ秒以上かかっていたクエリの例:
↓は、作成した固定ページTOPにアクセスした際のクエリの1つ、2度目以降、このクエリは発行されなくなった?
UPDATE wp_options SET option_value = '1336700006' WHERE option_name = '_transient_doing_cron'
do_action, wp_cron, spawn_cron, set_transient, update_option #2 (278.3ms)
↓は、ダッシュボード内の[更新]にアクセスした際のクエリ2つ
SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'
wp_not_installed, is_blog_installed, wp_load_alloptions #1 (804.1ms)
UPDATE <code>wp_options</code> SET <code>option_value</code> = 'O:8:\"stdClass\":1:{s:12:\"last_checked\";i:1234567890;}' WHERE <code>option_name</code> = '_site_transient_update_themes'
do_action, wp_update_themes, set_site_transient, update_site_option, update_option #8 (269.3ms)
しばらくアクセスを止め、時間を置いて再度アクセスするなど、引き続き確認していきます。
Debugで確認するべきメニュー、ポイント、やり方などありましたら、教えて頂ければと思います。
それほど詳しいわけではないので恐縮ですが、いくつか切り分けのために
試してみたらどうかと思う点を以下にあげます。
※もしすでに試していたら、すみません。
1.可能でしたらproxyを介さずにアクセスしてみる
2.ApacheのエラーログでWarningも含め、何か思い当たるものがないか
3.WordPressを最新版にしてみる
podspodさん
情報ありがとうございます。
1.可能でしたらproxyを介さずにアクセスしてみる
これは1度やってみました。問題ない速さでした。ただその時はproxy経由で数回アクセス後の徐々に速くなった後の検証でしたので、原因の切り分けにはなりませんでした。
表示遅延が発生しているタイミングで、また再度確認してみます。
2.ApacheのエラーログでWarningも含め、何か思い当たるものがないか
確認してみました。私の知識・調査不足でよく分かっていないエラーログは出ているのですが、表示遅延の発生タイミングで必ず出力されているものではなく、今のところ直接的な原因ではないのでは、と考えています。
3.WordPressを最新版にしてみる
・PHP:5.1.6 –> 5.3.3
・WordPress:3.1.4 –> 3.3.2
にアップデートしてみましたが、変化なしでした。
また、調べていると「WordPressでリバースプロキシすると無限ループする」という情報があったので、情報の通り「Disable Canonical URL Redirection」をインストールしてみましたが、変化なしでした。
それと、これはフォーラム内の別の方の質問ですが、「wordpressのバージョン更新確認時にproxyに阻まれることが原因」とありましたので、「Disable WordPress Updates」をインストールしてみました。
まだインストールしたばかりなので、時間をおいてアクセスするなど、しばらく様子を見てみます。
質問させて頂いていた本問題ですが、(はっきりとした原因は不明のまま)一まず解決しましたので、記載させて頂きます。
▼対応
WPで作成したBlogサイトへのアクセスは、proxyを経由してWP設置サーバへ転送しているが、そのWP設置サーバを別のサーバにリプレースした。
▼結果
初回アクセス含め、表示もデータ登録・更新も全く問題ない表示速度になった。
▼原因
旧サーバの具体的にどこが悪かったのかは不明。ハードウェア障害?
▼判断の経緯
- proxy経由なしで、複数回に分け時間をおいて、直接WP設置サーバへアクセスしてみたが、表示速度はやはり遅かった。
- その旧サーバの管理者がサーバにSSHでログイン、確認作業でcdやlsといった大した負荷のないコマンドを入力したが、管理者の経験・感覚からして、その応答が帰ってくる速度が異常に遅かった。
- 一度リブートを実行したが、なかなか始まらない終わらないで、リブート作業も異常に時間がかかった。
などの事象が見られたため、WordPressとか、Proxy経由とかのアプリケーション・ネットワークの問題ではなく、サーバ筐体そのものが問題と判断し、サーバをリプレースした。
jim912さん、podspodさん
アドバイスなど、ありがとうございました。致命的な問題が(とりあえず)解決し、ようやくサービスが開始できそうです。