D7サイトとMinelliサブテーマをまとめました。その過程で、さまざまなテーマ、さまざまなモジュールで多くのことを実験しました。途中でどこかで奇妙なパフォーマンスの問題が発生しましたが、現在はどのテーマ/モジュール/構成が原因であるかわかりません。

問題は、最初にサイトにアクセスしたとき、最初のページが表示されるまで約15秒かかることです。その後、サイト内を移動でき、非常に反応がよいです。1時間ほど放置してから戻ってくると、最初の要求は非常に遅くなります。

キャッシュをクリアしたので、それは問題になりません。また、使用していないテーマとモジュールを無効にしました。サイトを新しいインフラストラクチャに移動しましたが、問題はそれに続きました。

次はどこに行きますか？

私がチェックする3つのことがあります。

1つ目は、実稼働サイトにいて、PHPファイルを編集していない場合、APCが有効であり、十分なメモリがあり、TTLが長いことを確認する必要があります（必要に応じて、1日で行くことも期限切れになることもありません）。設定を検討することもできますapc.stat=0。APCのドキュメントは、あなたがTTLを設定するために必要なすべての情報を持っています。メモリ量を選択するには、apc.phpファイルを保護された場所に貼り付け、メモリ使用量とチャーン統計を監視する必要があります。ミス率が非常に低くなるようにAPCメモリを調整します。APCがいっぱいで空になっているために初期の遅延が発生する可能性があります（IIRC、APCは、LRUまたはより高度なキャッシュ戦略を使用する代わりに、キャッシュがいっぱいになるとキャッシュ全体をダンプします）。

次に、MySQLが適切に調整されていることを確認します。mysqltunerを使用して、バッファサイズを調整できます。最初の遅延は、ディスクからのテーブルの読み込みやクエリキャッシュミスが原因である可能性があります。完全ではありませんが、mysqltunerは正しい方向に進みます。

第三に、実際のDrupal cron戦略があることを確認してください。個人的には、「admin / config / system / cron」で自動マジックcronを無効にし、毎晩実行するようにcrontabを設定します。物事をよりきめ細かく制御する必要がある場合は、Elysia Cronを試すこともできます。これにより、必要なタスクを必要な頻度で実行できますが、通常のタスクは夜間に実行できます。最初の遅延は、1時間ごとに発生するcronの実行による可能性があります。これを確認するには、cronが "admin / reports / dblog"で実行されるタイミングを確認し、速度の低下に合わせます。

Ivanhoe123はおそらく正しいです。Drupal7には、デフォルトで「poor mans cron」が有効になっています。要するに、Drupalがページをレンダリングする前に（しばらく）cronが実行され、すべてが遅れることを意味します。

本番サイトでは常に本物のcronジョブを使用してください。技術的な詳細については、http：//drupal.org/cronを参照するか、ホスティング会社に相談してください。

無効にするには、admin / config / system / cronに移動し、「Never」を選択します。

Develのあなたがどんな長いクエリを実行しているかどうかを確認するためにモジュールの提供するデータベース・ロギング。

それでも解決しない場合は、XHProfまたはXDebugを使用して、有罪コードを見つけてください。XHProf（プロファイラー）は、サーバーで実行されているすべての関数の素敵なマップを描画し、どの関数が最も実行時間を消費しているかを示します。一方、XDebug（デバッガー）がEclipseなどのIDEで構成されている場合（ビデオを参照）、ライブで実行されているすべての機能にドリルダウンできます。プロファイラーは、実行されているもののアイデアを提供します。デバッガーが実行されている理由を表示します。

質問の趣味から、すぐに3つのことを考えます

• MySQLストレージエンジン/ CPU
• データベースキャッシュ
• テーブルのロック

MySQLストレージエンジン

FULLTEXT検索/インデックス作成を使用していない場合、すべての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 Storage Engineはインデックスのみをキャッシュします。InnoDBはデータとインデックスをキャッシュします。これを考慮して、InnoDBバッファープールに次のいずれか（小さい方）を収容するのに十分なメモリを割り当てることができます。

• すべてのInnoDBデータとインデックス（OSにも十分なRAMがある場合に理想的です;その後の遅延を排除します）
• インストールされたRAMの75％（RAMのInnoDBデータ/インデックスがさらにある場合;遅延を最小限に抑える）

MySQL 5.1を使用している場合、innodb_max_dirty_pages_pct = 0を設定できます。これにより、ディスクI / Oがわずかに増加しますが、InnoDBバッファープールはディスクI / Oの急増なしで古いデータとインデックスページを回転できるように十分にクリアされます。MySQL 5.5およびMySQL 5.1のInnoDBプラグインは、より優れたデフォルトのバッファープールフラッシュメカニズムを備えているため、この調整は不要です。

InnoDBの使用が問題外の場合は、memcachedまたはワニスを使用する必要があります。これにより、開発者は、キャッシュされたデータがサーバーRAMに保持される期間を指定できます。当然、これにはアプリケーションをmemcached / varnishに対応させるために開発上の強化が必要です。

テーブルのロック

• InnoDBは行レベルのロックを行います。これにより、トランザクションと非ブロック読み取りが可能になります。
• MyISAMは、すべてのINSERT、UPDATE、およびDELETEに対して完全なテーブルロックのみを行います。

エピローグ

MySQLの再起動後の初期遅延は避けられません。ただし、前述の提案/情報を使用してMySQLを強化すると、その後の遅延は発生しなくなります。

YSlowやFirebugなどのツールを使用して、前述のページを読み込んだときと直後に言ったページを読み込んだときに何が起こっているかを正確に判断します。キャッシュの問題であるかどうかを確認し、さらに、匿名ユーザーとしてページにアクセスしてから認証済みユーザーとしてページにアクセスするときの機能を確認します。これをDrupal内のパフォーマンス設定と比較してください。

キャッシュの問題でない場合は、MySQLのログと同様にDevelのクエリログを使用して、データベースで何が起こっているかを確認します。さらに、サーバー上にオペコードまたは同様のパフォーマンス強化キャッシュがある場合、それらをオフにしてからオンにしていくつかの数値を取得してみてください。

cronが実行されているように聞こえます。

ここで設定を確認してください：admin / config / system / cron

このため、私は最後のプロジェクトのためにDrupalをほぼ削除しました。

ただし、複数の原因が必要です。この問題が忍び寄るたびに機能する「すべてを修正する」ソリューションはまだ見つかりません。

syslogおよびUbuntu / Debain

断続的な15秒間のロード時間に初めて遭遇したのは、Debian / Ubuntuベースの（専用の、非共有の）システムでdrupalを実行しているときでした。Syslogモジュールを無効にすることが私にとっての解決策でした。

@BetaRideが言ったように、xDebugまたは他のPHPプロファイラーを使用することは非常に有益です。

それでも問題-回避策

私の他のインストールに関しては、まだ迷っています。

この問題は、開発サーバーとトラフィックの少ないDrupalインストールでより顕著になります。

回避策として、60秒ごとにサイトのホームページをロードするcronジョブと、300秒ごとにDrupalのcronスクリプトをセットアップしました。これは明らかに最適ではありませんが、人間の訪問者ではなく15秒のロード時間を取得またはカールする方がましです。

多くの人は、この問題は同期バックグラウンドプロセスのブロック、特に重いcronジョブに関連する可能性があることを示唆しています。

trueの場合、gielfeldt *が積極的に開発中のモジュールのペアが存在します。このモジュールは、この問題を完全に解決するか、少なくともいくつかの手がかりを提供し、サイトビルダーが特定の犯人を診断および治療するのに役立ちます。どちらもブロッキング同期のプロセスを非ブロッキング非同期HTTPまたはコマンドに置き換え、両方とも問題のあるプロセスを特定できる関連レポートを提供します。

• バックグラウンドプロセスとそのバンドルモジュールにより、Drupalのバックグラウンドプロセスキューを非同期で処理できるため、ブロックされません。これにより問題が停止する可能性があります。また、最新の開発にバンドルされたバックグラウンドプロセスApacheサーバーモジュールには、これらのプロセスの開始時間と進行状況を監視、ロック解除、検査する機能を備えた基本的で改善されたUIレポートがあります。これにより、問題のプロセスを特定できます。
• Ultimate Cronは、バックグラウンドプロセスに基づいて構築され、cronでトリガーされたタスクが独自の個別の非同期スケジュールを持つことができます。各非同期スケジュールは、UIで監視および停止できます。定期的な低オーバーヘッドクリーンアップからヘビーデューティパフォーマンスマッピングタスクを分離するのに最適であるだけでなく、個々のcronトリガータスクの実行時間、最後の実行日時、現在のステータス、これにより、問題のプロセスからブロックを削除したり、問題のプロセスを特定したりできます。

とにかく両方とも非常に便利なモジュールです。この問題のために、それらは、ブロッキングが同期ブロッキングプロセスまたはcronの実行によって引き起こされるという（非常にもっともらしい）理論をテストするために使用できます。潜在的には、これらを同期的にではなく非同期的に実行することで問題を解決でき、また、特定のプロセスがホールドアップを引き起こしていることについての手がかりを提供する可能性もあります。（彼らのドキュメントは非常に進行中の作業であることに注意してください...

ただし、まったく役立つように構成できない場合は、単なる同期バックグラウンドプロセス以上の問題があることを示唆しています。FWIW、これらのモジュールが適切に動作するようになったので、サイトでこの特定の問題は一度もありませんでした（しかし、木に触れます）-私は以前に自分のサイトで、そして野生のライブDrupalサイトでそれを見ました。

また、現在開発中の他の関連プラグインモジュールにも注意してください。たとえば、複雑な高強度の場合、しきい値ベースのスロットルを可能にするUltimate Cron Queue Scalerは、cron関連のパフォーマンスの問題を軽減するのに役立ちます。

* 所属なし、私は彼らの仕事に非常に感銘を受けたユーザーです

これがもう一度私を襲っているので、私は問題を調査します。私は間違いなくそれを確認できます

1. drupal_cron_run()コアのpoormanのcronによってトリガーされる呼び出しは、開発マシンでのリクエスト時間に約5秒を追加します。これはdrupal_cron_run()、modules/system/system.moduleinの呼び出しに関するテストのコメントを外すことでテストできます。system_run_automated_cron()
2. すべてのキャッシュをクリアすると、開発マシンのリクエスト時間が約2秒増えます。これをテストするには、a drush cc allを実行し、ページを再度リロードします。

つまり、cronをneverに設定し、crontabを介してcronへの呼び出しを追加すると、状況が大幅に改善されます。すぐにキャッシュを補充するために、よく使用されるページを押すと、ユーザーエクスペリエンスが再び悪化します。

キャッシングについてはわかりません。このサイトのデフォルトのキャッシュ設定は変更していません。drupalは、おそらくcronによってトリガーされる可能性があるすべてのキャッシュを時々再構築していると思いますが、これがどのように行われるかはわかりません。しかし、数時間後にページにアクセスすると、7秒の遅延がほとんど発生します。

このような問題は気が散る可能性があり、私が同じような状況にあったときは、問題が一度に1ステップずつ進行している原因を特定し、匿名のログユーザーとしてテストするのに役立ちます。（オニオンレイヤー法）

いくつかのテーマで遊んで、独自のカスタムコーディングを行った後に問題に気づき始めたと言います。サイトの複雑さやその背後にあるロジックはわかりませんが、次の手順は問題を見つけるのに役立ちます。

1. サーバーで、フォルダーまたは別のアカウントを作成します（これが良い場合があります）。ここで、サイトで使用しているのと同じバージョンで、Drupalのクリーンインストールを実行します。次に、モジュールやテーマを追加せずに、サイトが最初のリクエストと次のリクエストに応答するのにかかる時間をテストします。すべてが正常に機能する場合、サーバー構成の問題を無視できます。現在の問題と同じ動作をしている場合は、Webサーバーまたはデータベースで構成エラーが発生しています。

2. 手順1の結果が良好で、サーバーが高速に応答し、後続の要求が同じくらい速い場合、現在のサイトからテーマのみをクリーンインストールサイトにインストールして、もう一度テストします。それでもすべてが高速に応答する場合、テーマは問題ではないため、ステップ3に進む必要があります。そうでない場合は、テーマのデバッグを開始する必要があります* 1。

3. ステップ2のテスト後も、サイトが現在のサイトのモジュールをすぐに持ち込み、各モジュールを追加して有効にした後、応答時間をテストするようにしてください* 2。

4. テーマとモジュールを追加した後、サイトがまだ応答する場合、構成の追加をすぐに開始し、コンテンツタイプを作成し、ビューをインポートし、セットアップメニューなどを追加します。

5. セットアップと構成の準備が完了し、サイトはまだ高速ですが、データを引き継いでいます。ノード、分類用語、コメントなどをインポートします。壊れたレコードのように聞こえるはずですが、各ステップの完了後に必ずテストしてください。

* 1テーマのテスト：このプロセスは、非常に精巧なテーマでは扱いにくい場合があります。ここにいくつかのポインタを示します。

1. 外部のjsまたはcssライブラリにリンクする場合は、同じローカルコピーを使用してみてください。

2. template.phpファイルで、前処理関数やフックテーマ関数だけでなく、より長いループや無限ループがある可能性のある関数をチェックします。

3. 他のテンプレートファイル（page.tpl.phpなど）を確認し、配列とオブジェクトの生のPHP処理を探します。

4. 「ビュー」を使用してテンプレートファイルを表示する場合は、同様に確認してください。

5. 常にパスを再確認し、画像、js、cssファイルを最適化します。1つのファイルで複数のコードスニペットを使用すると、jsファイルの高さが大きくなる場合があります。

* 2モジュールのテスト： PHPでの重い操作の使用が許可されているため、モジュールのテストは少し異なります。以下にいくつかのポインタを示します。

1. コミュニティがサポートするモジュール（CCK、ビューなど）にはdrupal.orgの問題キューがあり、問題に関する既存の問題があるかどうかを確認し、修正するパッチがある可能性があるかどうかを確認します。

2. 独自のカスタムコード化モジュール、コード化した場合は修正する必要がありますか？コーディングを再確認し、api.drupal.orgに対して関数の使用法を確認してください。フックではなく、過剰な関数を使用している可能性があります。

3. インターネット共有カスタムコードモジュールは、手順2と同様に行いますが、今回は元のモジュール作成者に連絡して、問題について知らせることもできます。

4. サイトがアップグレード（D5-> D6-> D7）の場合、移行スクリプトまたはアップグレードスクリプト（通常はmodule.installファイル）を確認し、新しいテーブル構成に余分な「インデックス」が必要になることがあります。 。

5. 問題についてトンネルのビジョンがあると思う場合は、少し出て、まったく関係のない他のアクティビティをいくつか実行してから、後で戻って問題を再検討してください。

6. コードのセクションで問題をpingで指摘しても、それを修正する方法について頭も尻尾も作れない場合は、そのセクションがどのようにプログラムするのか、Drupalがどのように機能しているのか分からない人に何をするのかを説明してみてください驚きの準備ができています。

注：サイトを再構築した後、コンピューターが持つ最高の機能の1つである魅力のようにすべてが動作し始めても、心配しないでください。

モジュールをアンインストールせずに削除していないことを再確認してください。これにより、Drupalがファイルを見つけようとしますが、ファイルがもう存在しないため、遅延が発生します。

モジュールがもう存在しない場合、変数テーブルの参照を削除します。

newrelicなどのWeb APM は、パフォーマンスの問題を追跡するための最適なツールです。1〜2行のコードを呼び出して、奇妙なことを行い、不必要な配列をロードし、APMで追跡するまで見えないその他のことを行うサイトがありました。

誰かが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ブラウザで無料で読み込み時間を比較します。これを使用して、変更内容に応じて実際の結果を取得します。

問題はどこにでもある可能性があります。

1. テーマまたはモジュールでデバッグモードをオンにしていないことを確認してください。たとえば、多くのテーマにはテーマレジストリを再生成するオプションがあります。
2. Godaddyのような共有ホスティングで実行している場合、最初の15秒間のリクエストは正常です。
3. Drush CTools Exportモジュールを使用して、サイトまたはフロントページをコードベースに変換します。これにより、データベース呼び出しがなくなり、サイトは完全にphpから実行されます。
4. それでも問題が解決しない場合はquery log、でpage timerオプションをオンにしてDevel設定を使用しadmin/config/development/develます。2つのうちどちらがページ全体を生成するのに時間がかかるかを確認します。
5. 何も機能しない場合は、サーバーを再起動します。
6. 最悪の場合、XHProfをインストールして、問題が発生している場所を確認します。

これが、インストールの問題を修正した方法です。問題の正確な原因を特定できなかったため（実際に問題がある場合）、これは実際の解決策ではありませんが、適切な解決策です。

1）集計CSS（キャッシュ設定）。これにより、レイテンシーが半分に短縮されました

2）cronを設定しない（外部で実行する）-注：「すでに実行中のcronを起動しようとした」というエラーが発生しました。起動ごとにcronを起動しようとしていたと思いますが、失敗したため、cronページは最新の試みではなく、最新の成功について言及していました。

3）30分ごとにLynxでホームページを呼び出すcronジョブを設定します

これはすべて、共有ホスティングサーバー上で行われます。最適ではありませんが、動作します

Boostモジュール（共有ホスティングを使用している場合）またはVarnishのラインに沿ってフロントエンドキャッシュを使用することをお勧めします。これは、サイトへのアクセスが主に匿名であり、ページコンテンツがほとんどの部分で動的でない場合（つまり、ページがあまり変化しない場合）に最適です。

これらのソリューションは、最初のアクセス時にレンダリングされたページを保存してから、Drupalブートストラップ、ページ構築、テーマ設定プロセスをすべて実行する代わりに、事前にレンダリングされたhtmlを提供します。 「眠りにつく」ことを説明し、目覚めるのに時間がかかりすぎる。

唯一の本当の欠点は、（少なくともBoostの場合）サイトコンテンツが変更されたときにキャッシュをクリアする必要があることです。サイトが現在のコンテンツで完全にキャッシュされていることを確認する場合は、drush cc allを実行し、cronを使用して定期的にサイト全体に対してcurlまたはwgetを実行できます。