web-dev-qa-db-ja.com

遅いWordpressの管理者を診断するにはどうすればよいですか?

ここ数カ月間、私のwordpressマルチサイトサイト(およそ80サイト)の管理者ページはロードするのにおよそ20秒かかりました。最新版のワードプレス(バージョン4.1)を実行しています。

私がpluginsフォルダの名前を "plugins-deactivated"に変更したとき、管理領域は3秒の通常の元気いっぱいの速度に戻りました。しかし、フォルダの名前を「プラグイン」に戻すと、サイトは通常の20ロード時間に戻りました。それから私はすべてのプラグインを無効にしました、そしてプラグインが無効にされていても管理領域は通常の遅い速度のままでした。

私はすべてのプラグインを削除し、それらを一つずつ再アップロードしました - どのプラグインをアップロードしても、管理者は追加の各プラグインを遅くしました。描くべき明白な結論は、Wordpressが起動されているかどうかにかかわらず、あらゆるプラグインをロードしているということです。

私の質問 - どうすればこの仮定を検証できますか?また、どのようにして問題をさらに診断できますか?

他のいくつかの事実

  1. このサイトは約80サイトのワードプレスマルチサイトです。
  2. Windows Azure上で実行されています
  3. 問題は過去数ヶ月で始まりました
  4. すべてのプラグインが有効になっています
  5. クエリモニタプラグインを実行しています
  6. インストールは約8歳です

どのようにしてスローが発生したのかを見つけることができますか?

アップデート1: 私はChrome Dev Toolsを使用しました - そしてロード速度の約95%は最初のGetリクエストにあります - これは問題がサーバー上で起こっていることを示唆するようです補助荷重項目がない

Update 2: Gravity Formsプラグインが存在するだけで、サイトの読み込み時間が約9秒長くなります。プラグインが非アクティブ化されたときに起こります。

Update 3: データベースを最適化しても効果がない。

5
Steve French

問題はWordPressのバージョンにあるようです - MultiSiteを実行している間特にWordPress 4.1 - 私は4.0.1にダウングレードし、問題のすべてが消えました。

0
Steve French

無効にしてもすべてのプラグインの読み込みについて話すことはできませんが、重力フォームは大量の使用を想定して設計されていないため、問題の大きな原因になっている可能性があります。


私は以前は重力フォームを使用していた大規模なクライアントと仕事をしていましたが、管理パネル(およびフォームの送信)が非常に遅くなったため、最終的に完全にタイムアウトし始めました。

私はもう細部については触れていませんが、当時の重力フォームに関する問題は、フォームが送信されると、重力フォームが以下のことをするということでした。

  • これまでに送信されたすべてのフォームをロードします
  • それが終わりに達するまでそれらのそれぞれを循環します
  • 最後に送信されたエントリを使用して、次の一意のIDを生成するためにエントリを追加します

当時、私はクライアント用のパッチを作成し、それをテストし、それを適用し、そして重力フォームにそれを提出しました…そして決して聞かれませんでした。次の数回クライアントが重力フォームをアップグレードしたとき、それは同じ問題を抱えていた、そして私はパッチを再適用しなければならなかった。私はついに彼らにサービスを切り替えるようになった。


Wordpressの管理パネルに追加の列を追加するプラグイン(例:リスト投稿、リストページなど)を使用している場合、少なくとも問題の一部となるのは、ほとんどのプラグイン作者が以下のクエリを使用することです。システム内の各項目は、適切な管理クエリを変更して投稿結果に求めるものを含めるのではなく、リストを変更します。

大きな警告

  • あなたがphpに完全に慣れていないなら、これを試みないでください
  • 可能であれば、最初にステージングサーバーでこれを行います _あなたが何かを壊さないようにするために_ _
  • 編集する前に必ず編集しようとしているファイルをすべてバックアップしてくださいを忘れないでください。必要に応じてすぐに元に戻すことができます。

そうは言っても、私が考えることができる唯一のことはtermporarily _次のようにwordpressのコアをハックすることだろう。

(4.1を実行している場合):

デバッグログを有効にし、エラーの公開表示を無効にします(wp-config.php):

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

これにより、テーマディレクトリにデバッグログファイルが作成されます。

wp-settings.phpを編集して、213行目から216行目で以下を見つけます。

foreach ( wp_get_active_and_valid_plugins() as $plugin ) {
   wp_register_plugin_realpath( $plugin );
   include_once( $plugin );
}

次のように変更してください。

foreach ( wp_get_active_and_valid_plugins() as $plugin ) {
   wp_register_plugin_realpath( $plugin );
   $start_at = time();
   if ( WP_DEBUG_LOG ) {
      error_log("Loading plugin {$plugin}\r\n\t Start: {$start_at}");
   }
   include_once( $plugin );
   $end_at = time();
   if ( WP_DEBUG_LOG ) {
      error_log("\t Finished: {$end_at}");
      error_log("\t Total Time: " . $end_at - $start_at . '(s)' );
   }
}

最初のロード時にプラグインが何か悪いことをしているかどうかだけがわかります。

同じファイルの237行目にあるdo_action( 'plugins_loaded')コマンドについても、一時的に同じことを実行できますが、それはすべてのプラグインがロードされるまでの時間を示すだけです。

それぞれの時間を確認するには、優先度1でplugins_loadedにフックし、すべてのplugins_loadedフックを読み取り、それらをすべて異なる優先度に更新してから、各間隔のタイムスタンプを記録する独自のplugins_loadedアクションを追加します。

例えば.

最初のプラグインを使用してすべてのプラグインを設定し、最初にロードしたプラグインのロード数が10、2番目のプラグインのロード数が12などになるようにします。

9:始めました

11:1秒(タイムスタンプnnnnnnnnnn)

13:0秒(タイムスタンプnnnnnnn)

15:8秒(タイムスタンプnnnnnn)

これはおそらく大量の助けにはならないことを私は知っていますが、それは少なくともあなたが犯人が何であるかをあなたに知らせるかもしれません。

上記のdebugコマンドを使用すると、フロントエンドにエラーを表示して、誤ったプラグインがサイトをクラッシュさせずに作業時間を記録するために、慎重に一時的な編集を行います。

9
Privateer

debug bar を知っていますか?追加してSAVEQUERIESを有効にすると、すべてのクエリにかかる時間を確認できます。

define( 'SAVEQUERIES', true );

その後、デバッグバープラグインを追加して他のものをプロファイルすることができます。 デバッグバーのリモートリクエスト リモートリクエストの場合および デバッグバーの遅いアクション の場合はWordPressフックをプロファイルできます。

ほとんどの場合、単一のボトルネックを簡単に見つけることができます。最初に最大のものに焦点を絞ります。それがどこから来ているのか特定するようにしてください。

この方法でボトルネックが見つからない場合は、PHPプロファイリングに飛び込む必要がありますが、PHP経験がなければそれはほぼ不可能です。

0

私の経験では、あなたのサイトをWindowsからApache Web Serverに移行するつもりなら、ApacheはWordPressのようなPhpアプリケーションにとってより効率的であるので、あなたは約40%のスピードアップを得るでしょう。

それでもあなたが引き返す選択肢がない場合は、 WindowsでWordPressのパフォーマンスを向上させる10の方法 を試す必要があります。

また、各プラグインのロード時間を分析するために P3(Plugin Performance Profiler) を使用することをお勧めします。

0