パフォーマンスログモジュールを使用しています。スクリーンショットの上で、奇妙なことに、すべてのページにCache_bootstrapを挿入していることに気付きました。任意のページ（管理テーマとフロントエンドテーマの両方）に移動すると、キャッシュを挿入してからキャッシュを削除します。これは、キャッシュが各ページで設定および破棄され、実際にはキャッシュが発生していないことを意味します。どうすればさらに詳しく説明できますか？現在、サイトのパフォーマンスに取り組んでいるため、その問題を診断します。
パフォーマンスチェックにもNew Relicを使用しています。また、データベースの負荷が高いことも示しています。
およびmy.cnf情報。
回答:
私のパフォーマンスプレゼンテーションのスライド＃85で、MySQLの最大パケットサイズについて説明しています。この値を増やす必要があります。SET GLOBAL max_allowed_packet=33554432;または構成ファイルhttps://dev.mysql.com/doc/refman/5.7/en/packet-too-large.html内で変更する
最大許可パケットサイズは、これが発生している1つの理由である可能性がありますが、この場合はおそらく別の理由であるという複数の理由がわかります。
このパターンの最も一般的な理由は、すべてのページで発生するvariable_set（）呼び出しです。xhprofを使用するか、xdebugを使用してブレークポイントを設定するか、debug_print_backtrace（DEBUG_BACKTRACE_NO_ARGS）を追加して、これらのキャッシュの削除がどこから行われているかを確認します。そこにvariable_set（）の呼び出しが表示されることは間違いありません。
問題は、変数に対して単一のグローバルキャッシュが存在することです。キャッシュへの書き込みが行われるたびにキャッシュが削除され、次のリクエストで{variables}テーブル全体が読み取られてキャッシュに書き戻されます。
多くの開発者はそれに気づいておらず、.moduleファイルまたはすべてのリクエストで実行される別の場所でvariable_set（）を直接呼び出すことによって「値を保証する」などのことを行っています。
これは単なる仮説ですが、ページの読み込みごとにブートストラップキャッシュが再構築されると、モジュールの一部がモジュールフォルダーにないが、システムテーブルにはまだ存在する場合があります。各ページでdrupalはそれを見つけてbootstrap_cacheを再構築しようとします。
Bootstrapオプティマイザモジュールを試してください。そのようなレコードを見つけて削除するのに役立ちます。