长时间运行的管理页面请求阻止其他请求

如果我登录到Magento的后端并执行一些需要很长时间的任务（在大型目录上进行全局搜索，长时间运行的数据流等），则我的Web浏览器将拒绝仅在该浏览器中加载其他管理页面。为什么会发生这种情况，并且有任何已知的解决方法科学？

也就是说，如果我

1. 登录到Magento的仪表板页面

2. 使用任何Magento管理页面打开第二个标签页

3. 在第一个标签中执行长时间运行的全局搜索（以sleep(30)开头的调用模拟globalSearchAction）

4. 尝试重新加载第二个标签

预期的行为：第二个选项卡立即加载页面内容

实际行为：只有长时间运行的全局搜索完成后，才会加载第二个选项卡

有谁知道具体为什么会这样？（我的猜测是Magento管理控制台请求锁定了Magento需要引导的某些资源，但我不知道那是什么）

有人知道修复/解决方法吗？

该问题是由PHP会话处理程序放置的锁引起的。因此，这不是Magento明确锁定某些内容并试图阻止管理员请求，而是基于文件的会话存储本身的几乎副作用。

当通过初始（长时间运行）请求打开会话数据文件时，会将写锁放置在会话数据文件上，从而导致第二个请求阻塞，直到调用它时释放该锁为止session_start。Mage_Core_Model_Session_Abstract_Varien::start

这是100％可复制的。我使用了与您相同的方法，sleep(30)在Mage_Adminhtml_IndexController::globalSearchAction

值得注意的是，如果您正在使用数据库会话存储，则无法复制。找到根本原因后，我将一个沙箱设置为数据库会话存储，不再能够重现该问题。因此，Magento的数据库会话处理程序似乎不使用行级锁定来锁定会话写入。我发现这很有趣，因为它有可能丢失会话数据，因为该应用程序显然没有考虑写入同一会话的多个线程。读者注意事项：我绝不会在生产中使用db会话存储来尝试解决此问题，这仅适用于重载MySql数据库。

我没有尝试使用基于内存的会话存储系统（例如Redis）来重现该行为，但我的猜测是在这些存储中也可能忽略了锁定会话存储中的记录。

有一些技术可以避免这种情况，例如session_write_close在开始长期运行的作业之前先使用释放锁。但是，这也将阻止您写入该会话，因为您刚刚将其关闭。因此，它不太可能在Magento中全面实现，而有可能在特定的路径/控制器上实现。

我将其固定为根本原因的技术是启用Xdebug分析器并检查“ cachegrind”文件。第二个请求完成后，我将输出文件（约25 MB日志）加载到MacCallGrind中，并沿着包含最终时间为28秒或更长的调用路径深入到跟踪中。最终，我session_start花了大约28秒才能完成通话，这给了我很好的研究依据。

编辑：对于感兴趣的人，我已经在Twitter的MacCallGrind中发布了 “ cachegrind”文件的屏幕截图。