我们在Varnish经营Magento商店。一切正常，除了以下问题：如果你打开一个商店页面，然后让浏览器打开很长时间，比如12-24小时，然后重新加载页面，页面加载非常慢（大约15s）。
我们在app / code / core / Mage / Core / Model / Session / Abstract.php中的start_session（）调用中找到了问题。此通话大约需要15秒。
我们使用memcache（不是memcached）进行会话管理。
我们搜索了很多内容，并发现了许多有关慢速会话开始的帖子，但没有关于此特定问题的帖子。
有人可以帮忙吗？
非常感谢， 蒂尔曼
答案 0 :(得分：1)
我在New Relic上也看过很多。
从我所看到的有几个不同的原因，我没有完全理解这个问题，但这是我最近一直在研究的问题。这是我的发现。
Magento，Locking和New Relic中的会话
Magento中的每个控制器操作都使用会话，无论是否需要。会话在Mage_Core_Controller_Varien_Action :: preDispatch
中得到了热切的实例化如果启用了会话锁定，则意味着在请求期间，会话将被锁定，直到请求完成。我还没有找到释放会话锁的代码，但我很确定它就在那里。
最终，这意味着如果您使用同一会话从一个位置触发对Magento控制器操作的多个并发请求，则必须等待其中一些请求完成并解锁会话才能继续。我通常认为这是对Mage_Core_Model_Session_Abstract_Varien ::开始约30秒的新遗物的缓慢交易（我认为我的会话锁等待超时）。
关于New Relic的这份报告在我看来时有多重缺点
减慢总平均响应时间，因为这些请求比本来应该的要慢。 New Relic记录了最慢的事务的样本，如果我有性能瓶颈，例如20秒，如果相同的URL受到会话锁定超时的影响，New Relic将不会自动报告它们。超时隐藏了有用的数据。 原因
我已经看到了一些常见的原因，无论如何都不是明确的清单
<强> 机器人
像百度和Yandex这样的爬行者有点粗鲁并且殴打网站。它们从一个位置运行，使用相同的会话触发大量请求，并使会话锁定机制瘫痪，从而显示New Relic中的慢速事务。
Ajax调用Magento控制器操作
对于涂漆网站，必须小心加载客户特定数据，一些网站通过使用对Magento后端的Ajax调用来管理这一点以获取所需数据。我还看到一些网站使用ajax调用后端来获取产品特定信息，例如商品在售时剩余的库存量。
如果单个页面在页面加载时触发对后端的多个ajax调用，则可能会触发会话锁定机制。 ajax回调到Magento后端的次数越多，你就越有可能遇到锁定。
清漆ESI
与上述相同，除了使用ajax调用之外，它使用Edge Side Includes，这似乎是对后端的新调用。
我的计划
我还没有采取行动，所以它仍然纯粹是理论上的，但这是我在接下来的几个月里所做的事情。
我在Mage Titans UK 2016大会期间提出了这个问题，Fabrizio Branca向我指出了以下模块：https://github.com/AOEpeople/Aoe_BlackHoleSession。
基于正则表达式，该模块将阻止Bots创建真实会话，这应该具有不会遇到会话锁定的好处，并且您的会话资源不会受到粗鲁机器人的攻击。机器人不应再污染你的新遗物读物。
对于ajax / ESI调用在缓存页面上获取客户数据，我无法看到任何事情。您需要访问会话才能检索客户特定数据。
但是，对于ajax / ESI调用获取目录特定数据（例如有限库存），我认为根本不需要在该请求上存在会话。我对未来的计划是试用Aoe_BlackHoleSession模块的扩展，以便我可以将对特定URL的请求封锁为无会话。
我对ESI的内部结构不太熟悉，所以很遗憾我没有太多评论。
替代
在会议期间，Fabrizio Branca表示他能够完全禁用会话锁定而不会产生任何不良影响，请自行承担测试。