回答:
私はこれをNew Relicでもかなり見ました。
私が見てきたことから、いくつかの異なる原因があり、この問題を完全には理解していませんが、最近調べてきたものです。これが私の発見です。
Magentoのすべてのコントローラーアクションは、必要かどうかにかかわらず、セッションを使用します。セッションはMage_Core_Controller_Varien_Action :: preDispatchで積極的にインスタンス化されます
セッションのロックを有効にしている場合、これはリクエストの期間中、リクエストが完了するまでセッションがロックダウンされることを意味します。セッションロックを解除するコードをまだ見つけていませんが、どこかにあると確信しています。
最終的にこれは、同じセッションを使用して1つの場所からMagentoコントローラーアクションへの複数の同時リクエストを実行する場合、それらのリクエストの一部が完了するまで待機し、セッションのロックを解除して処理を続行することを意味します。私は通常、これがMage_Core_Model_Session_Abstract_Varien::start〜30秒でスタックしている新しいレリックでの遅いトランザクションと見なします（私のセッションロック待機タイムアウト）。
New Relicに関するこのレポートには、複数の欠点があります
私はこれに関するいくつかの一般的な原因を見てきましたが、決して決定的なリストではありません
BaiduやYandexのようなクローラーは少し無作法であり、ウェブサイトを虐待しています。1つの場所から実行されており、同じセッションを使用して多数のリクエストを実行し、セッションロックメカニズムを作動させているため、New Relicで遅いトランザクションを示しています。
ニスを塗ったWebサイトでは、顧客固有のデータを注意してロードする必要があります。一部のWebサイトでは、Magentoバックエンドへのajax呼び出しを使用してこれを管理し、必要なデータを取得します。また、バックエンドへのajax呼び出しを使用して、商品の販売時に在庫に残っている量などの製品固有の情報を取得するWebサイトを見てきました。
1つのページがページの読み込み時にバックエンドへの複数のajax呼び出しをトリガーする場合、潜在的にセッションロックメカニズムをトリガーできます。Magentoバックエンドへのajaxコールバックが多いほど、ロックが発生する可能性が高くなります。
実際には上記と同じですが、ajax呼び出しを使用する代わりに、バックエンドへの新しい呼び出しと思われるEdge Side Includesを使用します。
私はまだこれを実行していないので、まだ純粋に理論的なものですが、今後数か月にわたってやろうとしていることです。
Mage Titans UK 2016カンファレンスでこの問題を取り上げたところ、ファブリツィオブランカは次のモジュールについて指摘してくれました：https : //github.com/AOEpeople/Aoe_BlackHoleSession。
正規表現に基づいて、モジュールはボットが実際のセッションを作成するのを防ぎます。これにより、セッションロックがヒットせず、セッションリソースが無礼なボットによって破壊されないという利点があります。ボットがNew Relicの読み取り値を汚染することはもうありません。
キャッシュされたページで顧客データを取得するajax / ESI呼び出しについては、私が見ることができることは何もありません。顧客固有のデータを取得するには、セッションにアクセスする必要があります。
ただし、カタログに固有のデータ（限られた在庫など）を取得するためのajax / ESI呼び出しの場合、そのリクエストにセッションが存在する必要はまったくありません。私の将来の計画は、Aoe_BlackHoleSessionモジュールの拡張機能を試用して、特定のURLへのリクエストをセッションレスとしてサイロ化することです。
私はESIの内部にあまり詳しくないので、残念ながらそこにコメントすることはあまりありません。
カンファレンス中、ファブリツィオブランカは、悪影響なしでセッションロックを完全に無効にできると述べました。自己責任でテストしてください。