Mage_Core_Model_Session_Abstract_Varien :: start的响应时间长

因此，我在许多站点上都注意到了New Relic，由于Mage_Core_Model_Session_Abstract_Varien :: start导致了很多长页面加载。我做了一些研究，还没有真正看到其他人在谈论这个。

我们使用Nginx，PHP FPM，Redis进行缓存，并使用Memcache进行会话。我的一些想法是，也许这是永久的事情，看来加载会话是问题所在。或以某种方式有一些自定义代码将大量数据添加到会话中，从而导致大量会话。

我对会话及其如何管理不了解，但是我发现一些文章讨论会话锁定。但是我认为人们不会同时打开这么多页面。

其中一些负载约为20到30秒。我只是想知道是否还有其他人注意到了这一点，或者对如何分析由于会话而产生的这类长请求有更多的了解。

performance session

— dan.codes
source

我注意到与Redis用作会话存储的行为相同。也不知道为什么会发生。

您是否能够找到造成这种情况的原因？我有一个非常相似的设置（Redis用于缓存，memcached用于会话），并且我们最近开始使用New Relic来跟踪性能。正如您所看到的，我们正在捕获大约20秒钟的第二次跟踪，这些跟踪似乎是由MCMSAV :: start中的某些事件引起的。不幸的是，我看不到它的更深层次，工具提示说：“更深的可见性不可用，因为这些类和方法未使用PHP代理的当前配置进行检测”。我尚未进一步调查。有任何想法吗？

— BrianVPS 2015年

@BrianVPS我什么也没找到。这对我来说仍然是一个谜，从未有更多的时间来追踪它。我仍然在每个项目中都看到它。你有没有发现？

— dan.codes 2016年

我不知道是否找到任何原因，但是最近还没有看到。我们对该站点进行了重大更改，并减少了很多脂肪。我禁用了一些未使用的核心模块，删除了大量未使用的属性，类别和产品。从那时起，所有方面的情况都得到了改善。我不知道它们是否相关，但总的来说，摆脱不必要的东西似乎对Magento很有帮助。这是一个功能强大但but肿的系统，其中包含许多站点不需要的许多代码。消除多余的部分非常有帮助。

— BrianVPS '16

@BrianVPS我遇到了与您完全相同的问题（20多秒钟的跟踪似乎是由MCMSAV :: start引起的）。您找到解决方案了吗？

— Denis Spalenza '16

这很可能与有关文件系统会话的现象有关。尽管您通过使用Mecached进行会话进行报告，但实际上我只是在使用文件系统时才亲自看到此消息。

这已经在这里覆盖了：

/magento//a/3721/336

实际上，Mage_Core_Model_Session_Abstract_Varien::start正如您正确指出的那样，缓存研磨的屏幕截图显示了会话启动花费过多时间的确切时间：

在此处输入图片说明

在所引用的线程中，有人建议使用内存中的会话存储可以减轻这种影响-但我所知道的不存在支持该理论的具体数据。如果您实际上使用的是memcached，则有理由认为，PHP级会话锁将在释放该锁之前阻止将来对会话存储的请求被授予。

通常，通常只在需要访问会话信息的请求上看到此消息，因此设计前端主题将有利于限制所需的访问量，从而避免在用户决定另一个标签或另一个长期运行的请求时避免潜在的锁定离开。

HTH，干杯。

— philwinkle
source