Magento + Varnish + Memcache：session_start（）が非常に遅い

Question

ワニでMagentoショップを運営しています。次の問題を除いてすべてうまくいきます：ショップページを開き、ブラウザを非常に長い時間（例えば12 - 24時間）開いたままにしてからページをリロードすると、ページが非常に遅く（約15秒）読み込まれます。

問題は、app/code/core/Mage/Core/Model/Session/Abstract.phpのstart_session（）呼び出しで検出されました。この呼び出しには約15秒かかります。

セッション管理にmemcached（memcachedではない）を使用します。

私たちは多くのグーグルで検索し、遅いセッションの開始については多くの投稿を見つけましたが、この特定の問題については何も見つかりませんでした。

anobodyは助けてもらえますか？事前に

多くのおかげで、 ティルマン

Answer 1

は、私も新しいR​​elicの上のこの非常に多くのことを見てきました。

私が見たことから、いくつかの異なる原因がありますが、私はこの問題を完全に理解していませんが、私が最近調べてきたことです。ここに私の発見です。 Magentoの、ロック、ニューRelicの

Magentoの内のすべてのコントローラのアクションで

セッションは、それが必要かどうか、セッションを使用しています。セッションはMage_Core_Controller_Varien_Action :: preDispatchで熱心にインスタンス化されます

セッションロックが有効になっている場合、これはリクエストの期間中、要求が完了するまでセッションがロックダウンされることを意味します。私はまだセッションロックを解除するコードのビットを発見していないが、私はそれがどこかにあると確信している。

最終的にこれは、同じセッションを使用して1つの場所からMagentoコントローラのアクションに対する複数の同時リクエストを起動した場合、セッションを完了してロックを解除して続行する必要があることを意味します。私は通常、Mage_Core_Model_Session_Abstract_Varien :: startで30秒（私のセッションのロック待機タイムアウトだと思います）の間、新しい遺物が滞っていることに気づきました。私はこれらの要求は、彼らがそうされている必要がありますよりも遅いので、それ

は、総平均応答時間が遅くなり見るよう

新しいRelicの上のこのレポートでは、複数の欠点を持っています。 New Relicは、パフォーマンスのボトルネックが20秒などの場合、最も遅いトランザクションのサンプルを記録します。新しいRelicは、セッションロックタイムアウトによって同じURLが犠牲になった場合、自動的にそれらを報告しません。タイムアウトは有用なデータを隠しています。 は私が百度とYandexのような

ボット

クロラがあること少し失礼や虐待されて任意の手段によって、このためのいくつかの一般的な原因ではなく、決定的なリストを見てきました

原因ウェブサイト。彼らは、同じセッションを使用して多数のリクエストを発し、セッションロックメカニズムをトリプルしているので、New Relicのトランザクションが遅くなっています。Ajaxは特定のデータは、注意してロードする必要がありニス塗りのウェブサイトの顧客とMagentoのコントローラアクション

への呼び出し

、いくつかのウェブサイトは、必要なデータを取得するためにMagentoのバックエンドへのAJAX呼び出しを使用してこれを管理します。また、バックエンドへのajax呼び出しを使用して、商品が販売されているときに在庫に残っている金額など、製品固有の情報を取得するウェブサイトもいくつか見てきました。

1ページでページロード時にバックエンドへの複数のajax呼び出しがトリガーされると、セッションロックメカニズムがトリガーされる可能性があります。より多くのajaxがMagentoバックエンドにコールすると、ロックを経験する可能性が高くなります。代わりに、AJAXを使用したのを除いて

ニスESI

本当に上記と同じことが、それは縁側がバックエンドへの新しいコールであるように思われたが含ま使用しています呼び出します。

マイプラン

それはまだ純粋に理論的ですので、私はまだこれをactionedしていないが、それは私が今後数ヶ月にわたりやっに探しています何か。

私はMage Titans UK 2016カンファレンスでこの問題を引き起こしました。Fabrizio Branca氏は私に以下のモジュール：https://github.com/AOEpeople/Aoe_BlackHoleSessionを指摘しました。

正規表現に基づいて、モジュールはボットが実際のセッションを作成するのを防ぎます。これは、セッションロックがヒットせず、セッションリソースが無礼なボットによって打ち負かされないという利点があります。ボットはもはやあなたの新しい遺物の読書を汚染するべきではありません。

キャッシュされたページに顧客データを取得するためのAjax/ESIコールでは、私が見ることができる何もありません。顧客固有のデータを取得するには、セッションにアクセスする必要があります。

しかし、Ajax/ESIコールではカタログ固有のデータ（限定在庫など）を取得するために、そのリクエストにセッションが存在する必要は全くありません。私の将来の計画は、Aoe_BlackHoleSessionモジュールの拡張を試して、特定のURLへのリクエストをセッションレスとしてサイロオフできるようにすることです。

私はESIの内部についてよく知らないので、残念ながらそこにコメントすることはあまりありません。

代替

会見ファブリツィオ・ブランカは、彼がどんな悪影響、ご自身の責任でテストすることなく、完全にロックセッションを無効にすることができたと述べました。