パフォーマンスの問題：最初のリクエストでの遅延
D7サイトとMinelliサブテーマを組み合わせました。その過程で、さまざまなテーマ、さまざまなモジュールを使っていろいろと実験しました。途中で奇妙なパフォーマンスの問題が発生しましたが、今はどのテーマ/モジュール/構成がそれを引き起こしたのか本当にわかりません。
問題は、最初にサイトにアクセスしたとき、最初のページが表示されるまでに約15秒かかるということです。その後、サイト内を移動することができ、非常に反応が速いです。 1時間ほど放置してから戻ってくると、最初のリクエストは再び非常に遅くなります。
キャッシュをクリアしたので、問題はないはずです。また、使用していないテーマやモジュールを無効にしました。サイトを新しいインフラストラクチャに移動しましたが、問題はそれに続きました！
次はどこに行きますか？
確認することは3つあります。
1つは、本番サイトにいて、PHPファイルを編集していない場合は、APCが有効であり、十分なメモリがあり、長いTTL =（1日で行くか、必要に応じて期限切れにしないこともできます。）apc.stat=0の設定を検討することもできます。 APC docs には、TTLの設定に必要なすべての情報があります。メモリ量を選択するには、apc.phpファイルを保護された場所に貼り付け、メモリ使用量とチャーン統計を監視する必要があります。ミス率が非常に低くなるようにAPCメモリを調整します。APCがいっぱいで空になっているために初期の速度が遅くなる可能性があります（ IIRC、APCは、LRUまたはより高度なキャッシュ戦略を採用する代わりに、キャッシュがいっぱいになるとキャッシュ全体をダンプします。
次に、MySQLが適切に調整されていることを確認します。 mysqltuner を使用して、バッファーサイズを調整できます。ディスクからのテーブルの読み込みやクエリキャッシュミスが原因で、最初の速度が低下した可能性があります。完璧ではありませんが、mysqltunerは正しい方向に進みます。
3番目に、本当の Drupal cron 戦略があることを確認します。個人的には、「admin/config/system/cron」でautomagic cronを無効にし、毎晩実行するようにcrontabを設定します。本当に細かく制御する必要がある場合は、 Elysia Cron を試すこともできます。このようにして、必要なタスクを必要なだけ実行できますが、通常のタスクは夜間に実行します。最初の速度低下は、1時間ごとに発生するcron実行が原因である可能性があります。これは、「admin/reports/dblog」でcronがいつ実行されるかを確認し、速度の低下に対応することで確認できます。
Ivanhoe123はおそらく正しいでしょう：Drupal 7はデフォルトで 'poor mans cron'が有効になっています。つまり、（しばらくの間）cronがDrupalページをレンダリングし、すべてを遅延させます。
常に本番サイトで実際のcronジョブを使用するようにしてください。技術的な詳細については http://drupal.org/cron を参照するか、ホスティング会社にご相談ください。
これを無効にするには、admin/config/system/cronに移動して、「しない」を選択します。
Devel モジュールは、長時間実行されているクエリがあるかどうかを確認するためのデータベースログを提供します。
これで問題が解決しない場合は、 XHProf または XDebug を使用して、有罪のコードを見つけてください。 XHProf（プロファイラー）は、サーバーで実行されているすべての関数のニースマップを描画し、どの関数が最も実行時間を消費しているかを示します。一方、XDebug（デバッガー）がEclipseなどのIDEなどで構成されている場合（ ビデオを参照 ）を使用すると、LIVEで実行されているすべての関数にドリルダウンできます。 。プロファイラーは、whatが実行されていることを示しますが、デバッガーはwhy実行されていますか。
質問の味から、すぐに3つのことを考えます
- MySQLストレージエンジン/ CPU
- データベースのキャッシュ
- テーブルのロック
MySQLストレージエンジン
フルテキスト検索/インデックス作成を使用していない場合は、すべてのMyISAMデータをInnoDBに変換することを強くお勧めします。 MyISAMは、複数のCPUと複数のコアを利用するように設計されていません。 InnoDBは、複数のCPUの使用と読み取り/書き込みハイパースレッディングのために大幅に強化されています。
InnoDBのパフォーマンスのためにMySQLをチューニングすることに関して、DBA StackExchangeとこのサイトでこれについて私が作成した投稿をいくつか示します。
Sep 20, 2011： マルチコアとMySQLパフォーマンスSep 12, 2011： MySQLで複数のコアを使用することも可能Jun 07, 2011： データベースをMyISAMからInnoDBに変換するにはどうすればよいですか？May 26, 2011： シングルスレッドデータベースとマルチスレッドデータベースのパフォーマンスについてApr 15, 2011： https://drupal.stackexchange.com/questions/1715/what-would-be-the-optimal-mysql-configuration-for-a-drupal-7-site/2367#2367 =
データベースキャッシュ
すべてのMyISAMデータをInnoDBに変換するもう1つの強力な論拠は、MySQLがデータ/インデックスをキャッシュする方法です。 MyISAMストレージエンジンはインデックスのみをキャッシュします。InnoDBはデータとインデックスをキャッシュします 。これを考慮して、InnoDBバッファープールに十分なメモリを割り当てて、次のいずれか小さい方に対応できます。
- すべてのInnoDBデータとインデックス（OSだけでなく、十分なRAMがある場合に理想的です。後続の遅延を排除します）
- インストール済みの75％RAM（より多くのInnoDBデータ/インデックスがある場合RAM;遅延を最小限に抑えます）
MySQL 5.1を使用している場合、 innodb_max_dirty_pages_pct = 0を設定できます。これにより、ディスクI/Oがわずかに増加しますが、 InnoDBバッファープールは、ディスクI/Oの急増なしで古いデータとインデックスページをローテーションアウトできるように十分にクリアされます。 MySQL 5.5およびMySQL 5.1のInnoDBプラグインは、デフォルトのバッファプールフラッシュメカニズムが優れているため、この調整は必要ありません。
InnoDBの使用が問題にならない場合は、memcachedまたはvarnishを使用する必要がある場合があります。これにより、開発者は、キャッシュされたデータがサーバーのRAMに存在する期間を指定できます。当然、アプリケーションをmemcached/varnish対応にするためには、開発の強化が必要です。
テーブルロック
- InnoDBは行レベルのロックを行うため、トランザクションと非ブロック化読み取りが可能です 。
- MyISAMはすべてのINSERT、UPDATE、およびDELETEに対して完全なテーブルロックのみを行います 。
エピローグ
MySQLの再起動後の初期遅延を回避することはできません。ただし、前述の提案/情報を使用してMySQLを拡張すると、その後の遅延は発生しなくなります。
YSlowやFirebugなどのツールを使用して、ページをロードしたときと直後にページをロードしたときに何が起こっているかを正確に判断します。キャッシングの問題かどうかを確認し、さらに、匿名ユーザーとして、次に認証済みユーザーとしてページにアクセスした場合の機能を確認します。これをDrupal内のパフォーマンス設定と比較してください。
キャッシングの問題でない場合は、DevelのクエリログとMySQLのログを使用して、w.r.tで何が起こっているかを確認します。データベース。さらに、サーバー上にオペコードまたは同様のパフォーマンス向上キャッシュがある場合は、それらをオフにしてから再度オンにしてみてください。
Cronが実行されているようです。
ここで設定を確認してください：admin/config/system/cron
この問題は、ブロッキング同期バックグラウンドプロセスに関連している可能性があり、特に重いcronジョブ。
Trueの場合、 gielfeldt *によって活発に開発されている優れたモジュールのペアが存在します。これにより、この問題が解決されるか、少なくとも、サイト構築者が特定の原因を診断して処理するのに役立つヒントが得られます。ケース。どちらもブロッキング同期プロセスをノンブロッキング非同期HTTPまたはコマンドに置き換え、問題のあるプロセスを特定できる関連レポートを提供します。
- バックグラウンドプロセス とそのバンドルモジュールにより、Drupalのバックグラウンドプロセスキューを非同期で処理できるため、ブロックされません。これは問題を停止する可能性があります。また、最新の開発にバンドルされたバックグラウンドプロセスApacheサーバーモジュールを使用すると、これらのプロセスの開始時間と進行状況を監視、ロック解除、および検査する機能を備えた、基本的だが改善されたUIレポートがあります。これにより、問題のプロセスを特定できます。
- ltimate Cron バックグラウンドプロセスに基づいて構築され、cronでトリガーされたタスクに独自の非同期非同期スケジュールを設定できます。各非同期スケジュールは、UIで監視および停止できます。ヘビーデューティパフォーマンスsappingタスクを通常の低オーバーヘッドクリーンアップから分離するのに最適であるだけでなく、個々のcronトリガータスクの実行時間、最後に実行された日時、現在のステータスなどの便利な情報を含むレポートも提供しますこれにより、問題のあるプロセスからブロッキングが削除されたり、問題のあるプロセスが特定されたりする場合もあります。
どちらも非常に便利なモジュールです。この問題の場合、それらは、閉塞が同期ブロッキングプロセスまたはcron実行によって引き起こされているという（非常にもっともらしい）理論をテストするために使用できます。潜在的には、同期ではなく非同期でこれらを実行することで問題を解決でき、特定のプロセスが停滞を引き起こしている手がかりを潜在的に提供することもできます。 （彼らのドキュメントは非常に進行中の作業であることに注意してください...
ただし、それらがまったく役立つように構成できない場合、同期バックグラウンドプロセス以外にも問題があることを示しています。 FWIW、これらのモジュールが正しく動作するようになってから（まだ-木に触れて）、サイトでこの特定の問題に遭遇したことがありません-しかし、以前に自分のサイトやライブDrupalサイトで見たことがあります野生で。
現在開発中の他の関連するプラグインモジュールにも注意してください。複雑な高強度のケースでは、しきい値ベースのスロットリングを可能にする ltimate Cron Queue Scaler は、cron関連のパフォーマンスの問題を軽減するのに役立ちます。
*所属なし、私は彼らの仕事の非常に感銘を受けたユーザーです
私は最後のプロジェクトでDrupalをドロップしたため、このためです。
しかし、私には複数の原因があるはずです。私はこの問題が忍び寄るたびに機能する「すべて修正」ソリューションをまだ見つけていません。
SyslogおよびUbuntu/Debain
断続的な15秒の読み込み時間に初めて遭遇したのは、（専用、非共有）Debian/Ubuntuベースのシステムでdrupalを実行しているときでした。Syslogモジュールを無効にする が私の解決策でした。
@BetaRideが言ったように、xDebugまたはその他のPHPプロファイラを使用することは非常に賢明です。
それでも問題-回避策
私の他のインストールに関しては、私はまだ途方に暮れています。
この問題は、開発サーバーとトラフィックの少ないDrupalインストールで顕著です。
回避策として、60秒ごとにサイトのホームページをロードするcronジョブと、300秒ごとにDrupalのcronスクリプトをセットアップしました。これは明らかに最適ではありませんが、人間の訪問者の代わりに15秒の読み込み時間を経験するのではなく、wgetまたはcurlを行います。
これはもう一度私を襲っていますので、問題を調査します。間違いなく確認できます
- コアの貧乏人のcronによってトリガーされる
drupal_cron_run()への呼び出しは、私の開発マシンのリクエスト時間に〜5秒を追加します。 _modules/system/system.module_ indrupal_cron_run()のsystem_run_automated_cron()の呼び出しに関するテストのコメントを外すことで、これをテストできます。 - すべてのキャッシュをクリアすると、開発マシンのリクエスト時間が〜2秒長くなります。これは、_
drush cc all_を実行してページを再ロードすることでテストできます。
つまり、cronをneverに設定し、crontabを介してcronへの呼び出しを追加すると、状況が大幅に改善されます。頻繁に使用するページをすぐにヒットしてキャッシュを補充すると、再びユーザーエクスペリエンスが損なわれます。
キャッシュについてはよくわかりません。このサイトのデフォルトのキャッシュ設定には触れていません。 drupalは、おそらくcronによってトリガーされたすべてのキャッシュを時々再構築していると思いますが、これがどのように行われるかはわかりません。しかし、7秒の遅延は、数時間後のページ。
誰かがGoDaddyが遅くなると述べました。 AWSのようなサービスにあるため、多くのクラウドベースのホスティング会社もこの最初の遅延があります。サーバーの優先順位を自動的に下げる方が安く、これらのサーバーは「起動」するのに1〜2秒必要です。
たとえば、Pagodaboxの最初のバイトは3〜4秒で、サーバーが正常に起動します。 Pagodaboxは実際にサーバーを稼働状態にしておくことで収益を上げているので、サイトを「カフェイン」するために追加料金を支払うことができます。
また、CDNが役立ちます。キャッシュされたページまたは画像を提供することで、web/dbサーバーに負荷がかかることはありません。ここで良いチュートリアル： http://wimleers.com/article/easy-drupal-cdn-integration-for-fun-and-profit
そして... WebPageTestは私を幸せにします。 http://www.webpagetest.org/ 世界中のさまざまなWebブラウザと無料で読み込み時間を比較します。これを使用して、行っている変更の実際の結果を取得します。
モジュールをアンインストールせずに削除していないことを再確認してください。 Drupalはファイルを見つけようとしますが、ファイルは存在しないため、これにより遅延が発生します。
モジュールがもう存在しない場合は、変数テーブルの参照を削除します。
newrelic などのWeb APMは、パフォーマンスの問題を追跡するための最良のツールです。変なことをしたり、不必要なときに不要な配列をロードしたり、APMでそれらを追跡するまでかなり見えない他のことを行ったりするコードの1行または2行を呼び出すサイトがあります。
このような問題はあなたを混乱させる可能性があり、私が同じような状況にあったときに、問題の原因を一度に1つずつ調べ、匿名でログに記録されたユーザーとしてテストするのに役立ちます。 （玉ねぎ層法）
いくつかのテーマを試して、独自のカスタムコーディングを行った後、問題に気づき始めると述べました。あなたのサイトやその背後にあるロジックがどれほど複雑かはわかりませんが、次の手順で問題を見つけることができます。
サーバーで、フォルダーまたは別のアカウントを作成します（これがより良い場合があります）。ここで、クリーンな場所で実行しますDrupalサイトで使用しているものと同じバージョンでインストールします。その後、モジュールを追加せずにまたは、サイトが最初の要求と次の要求に応答するのにかかる時間をテーマでテストします。すべてが適切に機能する場合は、サーバー構成の問題を無視できます。現在と同じように動作している場合は、Webに構成エラーがありますサーバーまたはデータベース。
手順1の結果が良好で、サーバーの応答が速く、後続の要求も同じくらい速い場合は、現在のサイトのテーマのみをクリーンインストールサイトにインストールして、もう一度テストします。それでもすべてが高速に応答する場合は、テーマに問題はなく、ステップ3に進む必要があります。そうでない場合は、テーマのデバッグを開始する必要があります* 1。
ステップ2のテスト後もサイトが高速で現在のサイトのモジュールを引き継いでいる場合は、各モジュールを追加して有効にした後の応答時間を必ずテストしてください* 2。
テーマとモジュールを追加した後もサイトが高速に応答する場合は、構成の追加、コンテンツタイプの作成、ビューのインポート、セットアップメニューなどを行います。それぞれを追加した後、サイトの応答をテストすることを忘れないでください。
セットアップと構成の準備が整っており、サイトはまだ高速です。今ではデータが転送されます。ノード、分類用語、コメントなどをインポートします。壊れたレコードのように聞こえるはずですが、各ステップを完了した後は必ずテストしてください。
* 1テーマのテスト：このプロセスは、非常に複雑なテーマではトリッキーになる可能性があります。いくつかのポインタを次に示します。
外部のjsまたはcssライブラリにリンクする場合は、同じローカルコピーを使用してみてください。
Template.phpファイルで、ループが長くなるか無限になる可能性のある関数、および前処理関数やフックテーマ関数を確認します。
他のテンプレートファイル（page.tpl.phpなど）を確認し、配列とオブジェクトのraw PHP処理）を探します。
「ビュー」とビューテンプレートファイルを使用している場合は、同様に確認してください。
常にパスを再確認し、画像、jsおよびcssファイルを最適化します。 1つのファイルで複数のコードスニペットを使用すると、jsファイルの高さが高くなることがあります。
* 2テストモジュール：テストモジュールは少し異なります。PHPでの激しい操作の使用が許可されています。ここにいくつかのポインタがあります：
コミュニティでサポートされているモジュール（CCK、ビューなど）にはdrupal.orgに問題キューがあります。問題について既存の問題がないかどうか、またそれを修正するパッチがある可能性があるかどうかを確認してください。
独自のカスタムコードモジュール。コード化した場合、修正する必要がありますよね。コーディングを再確認し、api.drupal.orgに対して関数の使用状況を確認してください。フックの代わりにオーバーキリング関数を使用している可能性があります。
インターネット共有のカスタムコードモジュール。手順2と同じですが、今回は、元のモジュールの作成者に連絡して、問題を知らせることもできます。
サイトがアップグレード（D5-> D6-> D7）の場合、移行またはアップグレードスクリプトをチェックし（通常はmodule.installファイルにあります）、遅いSQLクエリXを高速にするために、新しいテーブル構成に追加の「インデックス」が必要になる場合があります。 。
問題についてトンネルのビジョンがあると感じた場合は、少し一歩踏み出して、まったく関係のない他のアクティビティを行ってから、後で戻って問題を再検討してください。
コードのセクションでpingを実行しても問題の修正方法を正確に理解できない場合は、プログラムの方法や方法=Drupal仕事をして、驚かれる準備をしてください。
注：サイトを再構築した後、すべてがコンピュータが持つ最高の機能の1つである魅力のように動作し始めても心配しないでください。
問題はどこにでもある可能性があります。
- テーマやモジュールでデバッグモードをオンにしていないことを確認してください。たとえば、多くのテーマには、テーマレジストリを再生成するオプションがあります。
- Godaddyのような共有ホスティングで実行している場合、最初のリクエストの15秒は正常です。
- Drush CTools Export module を使用して、サイトまたはフロントページをコードベースに変換します。これにより、データベースの呼び出しがなくなり、サイトは完全にPHPから実行されます。
- それでも問題が解決しない場合は、
query logでpage timerおよびadmin/config/development/develオプションをオンにして、Devel設定を使用してください。 2つのうちどちらがページ全体の生成に時間がかかるかを確認します。 - 何も機能しない場合は、サーバーを再起動します。
- 最悪の場合のインストール XHProf 問題が発生している場所を確認します。
Boostモジュール（共有ホスティングを使用している場合）またはVarnishのフロントエンドキャッシュを使用することをお勧めします。これは、サイトへのアクセスが主に匿名であり、ページコンテンツがほとんどの場合動的でない場合（つまり、ページがあまり変化しない場合）に最適です。
これらのソリューションは、最初のアクセスでレンダリングされたページを保存してから、完全なDrupalブートストラップ、ページ作成、テーマ設定のプロセスを実行する代わりに、事前にレンダリングされたhtmlを提供します。これにより、特に忙しいサイトだけでなく、あなたが "眠りにつく"ことを説明し、目を覚ますのに時間がかかりすぎるようなサイトにも。
唯一の欠点は、（少なくともBoostの場合）サイトのコンテンツが変更されたときにキャッシュをクリアする必要があることです。サイトが現在のコンテンツで完全にキャッシュされていることを確認したい場合は、drush cc allを実行してから、cronを介してフルサイトに対して定期的にcurlまたはwgetを実行できます。
これがインストールの問題を修正した方法です。問題の正確な原因を特定することができなかったため、それは実際の解決策ではありませんが、良い修正です
1）CSS（キャッシュ設定）を集約します。これにより待ち時間が半分に短縮されました
2）cronをnever（および外部で実行）に設定します-注：「すでに実行中のcronを起動しようとした」エラーが発生しました。起動のたびにcronを起動しようとしたのではないかと思いますが、失敗したため、cronページでは最新の試みではなく、最新の成功について言及していました。
3）Lynxで30分ごとにホームページを呼び出すcronジョブを設定します
これらすべてが共有ホスティングサーバー上にあります。最適ではありませんが、機能します