ちなみに、このサーバーは企業内部のLANに接続されていて、ホストのアドレスには
http://172.xx.xx.xx/blog/
のように設定しています。
だとすると、DNS 回りの挙動があやしいですね。クライアントマシンのネットワーク設定、サーバーのネットワーク設定を確認してみてください。
このサーバーを閲覧する環境も、その企業の LAN 内部からですか? それとも、外部のインターネット回線からですか? WordPress を利用しない、静的な HTML のサイトの表示はどうですか?
余談ですが、「172.xx.xx.xx」は IP アドレスだと思いますが、例示用の IP アドレスというのがありまして、192.0.2.0/24 が用意されています (192.0.2.0〜192.0.2.255)。プライベートアドレスの例示は、実際と同じ 192.168.0.0/16 で構いません (グローバルに重複することがないため)。
トピック投稿者
748075
早速対応頂きましてありがとうございます。
wordpressがインストールされているサーバーのネットワーク環境の設定は問題無いと思います。
このサーバー上でfirefoxを動かし、外部のwebもストレス無く閲覧できますが、localhost/blog
でwordpressを見ると1画面毎に数分かかります。localhostは設定されているアドレス 172.16.xx.xx/21 に置き換えられます。(当然でしょうが)
同じサブネット内の他のマシンから接続(IPアドレスで)しても、やはり1画面毎に表示までに数分かかります。
wordpressがインストールされているサーバーのネットワーク環境の設定は問題無いと思います。
「問題ない」の確認方法はどうされたでしょうか? そのサーバーに FTPd や sshd が動いていて、それらのアクセスは遅くない、ということでしょうか?
確認事項として上げた「WordPress 以外の静的な HTML ファイルのアクセス」はどうなんでしょうか?
静的な HTML ファイルは速度に問題がないとすれば、MySQL まわりの設定が不十分なのかもしれません。MySQL は localhost へのアクセスですか? 172.16.xx.xx へのアクセスですか?
localhostは設定されているアドレス 172.16.xx.xx/21 に置き換えられます。(当然でしょうが)
ありゃりゃ、172.16 だったらプライベートアドレスですね。それなら例示としてそのまま使っても大丈夫です。通常、localhost は 127.0.0.1 であり、(プライベートとはいえ) 他の IP アドレスに置き換えられるかどうかは環境依存です。
トピック投稿者
748075
説明不足で失礼いたしました。
そのサーバーに FTPd や sshd が動いていて、それらのアクセスは遅くない、ということでしょうか?
はい。FTPdや、静的なHTMLファイルの場合は遅くなりません。
MySQL は localhost へのアクセスですか? 172.16.xx.xx へのアクセスですか?
MySQLは localhost へのアクセスです。
localhostでアクセスして 172.16.21.39/に置き換えられるのは、WordPressの一般設定で
「WordPressのアドレス(URL)」と、「ブログのアドレス(URL)」に「http://172.16.21.39/blog」と設定しているためかと思います。
トピック投稿者
748075
今、処理時間を計測したところ、
ログイン画面でIDとパスワードを入力後、ログインボタンを押してから次の画面が表示されるまでの所要時間:2分35秒
設定ボタンを押してから一般設定の画面が表示されるまでの所要時間:1分30秒
でした。
トピック投稿者
748075
一旦、DBのすべてのテーブルを削除し、2.6をインストールしてみましたが、
設定後の最初のログイン画面を表示するのに、やはり数分かかります。
何か、解決のヒントになるようなことは有りませんでしょうか?
はい。FTPdや、静的なHTMLファイルの場合は遅くなりません。
となると、MySQL のアクセスに時間がかかっている可能性もありますね。
同じ MySQL を使うシステムとして、MediaWiki をインストールしてみるとどうでしょう?
もしくは、そのサーバーに phpMyAdmin が入っていれば、それの実行時間はどうでしょうか?
多少 PHP の知識があれば、自前で MySQL アクセスを行うスクリプトを書いてみてベンチする手もあるかと思います。
ログイン画面でIDとパスワードを入力後、ログインボタンを押してから次の画面が表示されるまでの所要時間:2分35秒
通常は1秒もかかりません。どのへんで時間がかかっているか調べたいところですね。おそらく初期化段階である wp-settings.php で時間がかかってそうなので、ところどころで時刻を echo させてみるとか。
トピック投稿者
748075
いろいろありがとうございます。
>もしくは、そのサーバーに phpMyAdmin が入っていれば、それの実行時間はどうでしょうか?
phpMyAdminでは、テーブルの参照など瞬時に帰ってきます。
>おそらく初期化段階である wp-settings.php で時間がかかってそうなので、ところどころで時刻を echo させてみるとか。
了解しました。この方法で調査してみます。
(なぜか逆クォートが効かなかったので全角の>を使いました)
トピック投稿者
748075
wp-settings.php に echo time_stop(1)
を入れて調べてみました。
結果、最後の
do_action('init')
の直前の表示は
0.3030.303
で、
直後が
69.56069.560
でしたので、ここで時間を要していると思われます。
トピック投稿者
748075
前の記事のように、wp-settings.phpでは549行目にある
do_acrion('init');
の実行に、約69秒を要しているところまでは調べられましたが、私の力ではこれ以上の解析は無理なようです。
他に調べるべきモジュールなどございましたら、ご指摘いただければ幸いです。
トピック投稿者
748075
遅い原因が解りました。
更新確認のため(?) wordpressサーバーへのアクセスで、プロキシに阻まれていたためのようです。
そこを止めて運用しておりますが、そのうち
プロキシ経由でアクセスするように変更して対処しようと思います。
匿名さん
まったく同じ症状で悩んでいます。私は2.7を使っていますが、
2.5の情報で結構ですので、
どのファイルを触ってwordpressサーバーへのアクセスを止めれば良いのか、
教えていただけないでしょうか?
更新確認のため(?) wordpressサーバーへのアクセスで、プロキシに阻まれていたためのようです。
横から失礼します。
monauralさん
どのファイルを触ってwordpressサーバーへのアクセスを止めれば良いのか、
教えていただけないでしょうか?
私は、MU 2.7で同じ症状で悩んでいて、適当ですが一応解決したので情報です。
wp_includes/update.php、
wp_remote_request(URL, $option)でapi.wordpress.orgに通信しているようです。
私は面倒だったので、この関数の呼び出しをコメントアウトしてしましました。
軽く見た感じ、本体,plugin,themeで通信しているようです。
//add_action( 'init', 'wp_version_check' );
//add_action( 'load-plugins.php', 'wp_update_plugins' );
//add_action( 'load-update.php', 'wp_update_plugins' );
//add_action( 'admin_init', '_maybe_update_plugins' );
//add_action( 'wp_update_plugins', 'wp_update_plugins' );
//add_action( 'admin_init', '_maybe_update_themes' );
//add_action( 'wp_update_themes', 'wp_update_themes' );
深くはおってないので、何か影響があるかもしれませんが、とても、速くなりますよ。
なんで、wordpressはproxyを意識してくれないんだろう。
本当は、proxy対応しても良いんですが、proxy対応した結果、
自動バージョンアップができるようになっても、本家に取り込まれなければ
本末転倒なので、二の足踏んでます
# 別で管理している2.7(旧バージョンからのアップデート品)には、
# 「Disable WordPress Core Update」, 「Disable WordPress Plugin Updates」
# なんていう、プラグインが入っていた。
# もしかしたら、このプラグインを使用した方がスマートなのかも。
synapさん
add_actionをコメントアウトしたらとても速くなりました!
参考にさせていただきありがとうございました。