为什么 PHP Symfony sfSessionStorage::initialize 有时需要很长时间？答案

【问题标题】：Why PHP Symfony sfSessionStorage::initialize sometimes takes a really (really) long time?为什么 PHP Symfony sfSessionStorage::initialize 有时需要很长时间？
【发布时间】：2016-02-15 14:39:03
【问题描述】：

我们有不同的 PHP 应用程序，在 symfony 1.4 和 symfony 2 中，它们都在某些时候有请求，其中 sfSessionStorage::initialize 需要非常长的时间。

我说的是要加载几分钟。以这个 newrelic 跟踪为例：

在这里您可以看到 sfSessionStorage::initialize 耗时 185 秒。我们已经调试了几天了，到目前为止还没有成功。我们查看了 GC 设置，事件尝试将会话存储在文件系统中的位置挂载到 RamDisk 中，但没有任何效果。

这可能是什么原因？你有没有遇到过同样的问题？非常感谢任何帮助，谢谢！

【问题讨论】：

有些人倾向于对问题投反对票并且从不解释原因。不要让它打扰你。
也许可以使用 blackfire.io 之类的东西来分析应用程序并准确查看该调用期间发生的情况，它可能会让您更深入地了解需要这么长时间的原因
你还没有做过什么疯狂的事情，比如跨多个请求共享会话文件？
您说您尝试使用 ram 磁盘，因此您的会话文件不可能存储在 nfs 安装的磁盘中，因为这不是网络问题。
不确定是否相关：forums.powweb.com/showthread.php?t=77977

标签： php performance symfony session io

【解决方案1】：

感谢@SomeHelpingDude 的评论指向此线程：https://forums.powweb.com/showthread.php?t=77977，其中提到了实现您自己的会话处理程序的可能性（http://www.php.net/manual/en/function.session-set-save-handler.php）。

我们这样做了，并实现了一个使用 memcached 的会话处理程序。现在问题已经解决了。

我假设会话处理（文件系统）的本机方式最终会遭受死锁和其他性能问题，这些问题只能通过完全不使用文件系统来避免。

我仍然对为什么 ramdisk 没有首先解决这个问题感到困惑，所以如果有人能解释这一点，我会改变接受的答案。谢谢！

【讨论】：

【解决方案2】：

strace 可能会对正在发生的事情有所了解。

假设您无法使用 cli 重现问题，我建议将进程数限制为 1（对于 mod_php 为 MaxRequestWorkers，对于 php_fpm 为 max_children），将 strace 附加到该进程并检查它挂起的位置。

以php_fpm为例：

打开/etc/php5/fpm/pool.d/www.conf并确保设置
```
pm = static  
pm.max_children = 1
```
重启php_fpm和nginx
grep aux | php找出进程id
sudo strace -p 后跟进程 ID
尝试重现问题

如果它在一个系统调用中停留了几分钟，你会在 strace 的标准输出中清楚地看到阻塞器。如果没有单个阻止程序，而是重复系统调用的长循环，您可能需要将其记录到文件中并稍后进行分析。例如。 sudo strace -p {pid} | tee /tmp/strace.log.

如果单个工作人员无法重现问题，请尝试增加工作人员的数量，并为所有进程捕获 strace。

【讨论】：

谢谢！我会试一试并更新结果。

【解决方案3】：

不确定这是否会有所帮助，但请检查一下。

如果您手动处理会话，那么您应该在frontend/config/factories.yml 中关闭会话

all:
  storage:
    class: sfSessionStorage
    param:
      auto_start: false

您应该看到Deactivating the Unused Features 以提高性能。

只是另一个猜测：

会话依赖于文件。因此，请检查您的系统是否能够打开会话所需的那么多文件。或者创建文件有什么问题。

【讨论】：

您好，感谢您的回答！不，我不是手动处理会话。此外，我没有看到任何关于打开文件数量的操作系统限制。如果我手动处理 sessios（我不是），您的回答指向避免创建重复的会话？