サイトのパフォーマンス、キャッシュが適切に機能していない


8

ここに画像の説明を入力してください

パフォーマンスログモジュールを使用しています。スクリーンショットの上で、奇妙なことに、すべてのページにCache_bootstrapを挿入していることに気付きました。任意のページ(管理テーマとフロントエンドテーマの両方)に移動すると、キャッシュを挿入してからキャッシュを削除します。これは、キャッシュが各ページで設定および破棄され、実際にはキャッシュが発生していないことを意味します。どうすればさらに詳しく説明できますか?現在、サイトのパフォーマンスに取り組んでいるため、その問題を診断します。

ここに画像の説明を入力してください

パフォーマンスチェックにもNew Relicを使用しています。また、データベースの負荷が高いことも示しています。

およびmy.cnf情報。

ここに画像の説明を入力してください

回答:



3

最大許可パケットサイズは、これが発生している1つの理由である可能性がありますが、この場合はおそらく別の理由であるという複数の理由がわかります。

  1. キャッシュへの書き込みだけでなく、明示的なキャッシュの削除も行われます。キャッシュ書き込みが失敗すると、キャッシュ書き込みが繰り返され、キャッシュミスが発生しますが、削除は発生しません。
  2. これはcache_bootstrapテーブルです。大きくなる可能性のあるキャッシュがいくつかありますが、それらは通常、そのビンからのものではありません。

このパターンの最も一般的な理由は、すべてのページで発生するvariable_set()呼び出しです。xhprofを使用するか、xdebugを使用してブレークポイントを設定するか、debug_print_backtrace(DEBUG_BACKTRACE_NO_ARGS)を追加して、これらのキャッシュの削除がどこから行われているかを確認します。そこにvariable_set()の呼び出しが表示されることは間違いありません。

問題は、変数に対して単一のグローバルキャッシュが存在することです。キャッシュへの書き込みが行われるたびにキャッシュが削除され、次のリクエストで{variables}テーブル全体が読み取られてキャッシュに書き戻されます。

多くの開発者はそれに気づいておらず、.moduleファイルまたはすべてのリクエストで実行される別の場所でvariable_set()を直接呼び出すことによって「値を保証する」などのことを行っています。


ええ..それはあなたが議論したvariable_set()の事実について私でも知らないほとんどの開発者は真実です。また、debug_print_backtrace(DEBUG_BACKTRACE_NO_ARGS)についても知ることができます。それをありがとう。:)
Mr. J

3

これは単なる仮説ですが、ページの読み込みごとにブートストラップキャッシュが再構築されると、モジュールの一部がモジュールフォルダーにないが、システムテーブルにはまだ存在する場合があります。各ページでdrupalはそれを見つけてbootstrap_cacheを再構築しようとします。

Bootstrapオプティマイザモジュールを試してください。そのようなレコードを見つけて削除するのに役立ちます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.