Magento varien会话在带有MEMCACHE会话存储的类别页面上启动非常慢

我memcache用于会话存储，并且在新的文物交易中注意到的类别页面上，varien会话开始可能需要30秒钟以上。

这可能与会话锁定有关，但是我认为使用内存缓存时这并不是真正的问题。

任何人都曾经遇到过这个问题或有什么想法可能导致这个问题。

我在New Relic上也看到了很多。

从我看到的原因来看，有几种不同的原因，我对这个问题没有完全的了解，但这是我最近一直在研究的问题。这是我的发现。

Magento，锁和新遗物中的会话

无论是否需要，Magento中的每个控制器动作都使用该会话。该会话在Mage_Core_Controller_Varien_Action :: preDispatch中急切实例化

如果您启用了会话锁定，这意味着在请求期间，您的会话将被锁定，直到请求完成。我还没有找到释放会话锁的代码，但是我很确定它在那里。

最终，这意味着如果您使用同一会话从一个位置触发对Magento控制器操作的多个并发请求，则必须等待其中一些请求完成并解锁会话才能继续。我通常认为这是对新消息的缓慢处理，停留时间Mage_Core_Model_Session_Abstract_Varien::start约为30秒（我认为会话锁定等待超时）。

我认为这份有关新遗物的报告有很多弊端

• 降低总平均响应时间，因为这些请求比原本应该的要慢。
• 如果我遇到性能瓶颈（例如花费20秒），New Relic会记录最慢事务的样本，如果会话锁定超时困扰相同的URL，New Relic将不会自动为我报告这些瓶颈。超时隐藏了有用的数据。

原因

我已经看到了一些常见原因，无论如何都没有确定的清单

机器人

诸如百度和Yandex之类的爬虫有点粗鲁，殴打该网站。它们是从一个位置运行的，使用同一会话触发大量请求，并触发会话锁定机制，因此在New Relic中显示缓慢的事务。

Ajax调用Magento控制器动作

使用清漆的网站时，必须小心加载客户特定的数据，某些网站通过使用对Magento后端的ajax调用来管理此数据，以获取所需的数据。我还看到一些网站使用ajax调用后端来获取特定于产品的信息，例如，某商品销售时剩余的库存量。

如果单个页面在页面加载时触发了对后端的多个ajax调用，则可能会触发会话锁定机制。越多的ajax回调到Magento后端，您越有可能遇到锁定。

清漆ESI

确实与上面相同，除了使用了Edge Side Includes而不是使用Ajax调用之外，它似乎是对后端的新调用。

我的计划

我还没有采取任何行动，因此它仍然纯粹是理论上的，但这是我接下来几个月要研究的事情。

我在Mage Titans UK 2016大会上提出了这个问题，而Fabrizio Branca向我介绍了以下模块：https : //github.com/AOEpeople/Aoe_BlackHoleSession。

基于正则表达式，该模块将阻止Bot创建真实的会话，这应带来的好处是不会击中任何会话锁，并且您的会话资源不会被粗鲁的bot破坏。机器人不应再污染您的新遗物读数。

对于ajax / ESI调用来说，要在缓存页面上获得客户数据，我无能为力。您需要访问会话才能检索特定于客户的数据。

但是，对于ajax / ESI调用以获取特定于目录的数据（例如有限的库存），我认为根本不需要在该请求上存在会话。我未来的计划是试用该Aoe_BlackHoleSession模块的扩展，以便我可以将对特定URL的请求隔离为无会话的。

我对ESI的内部知识不太熟悉，因此可悲的是，我对此没有太多评论。

替代

在会议上，Fabrizio Branca说他能够完全禁用会话锁定而没有任何不良影响，请自行承担测试的费用。