php - 将 session.gc_probability 和 session.gc_divisor 设置为 100% 是个坏主意吗？

Question

场景:

• 用户登录
• Cookie 设置为 session 时长
• 1 小时不活动后，我希望注销用户

我认为我可以如何解决这个问题:

• 将 session.gc_maxlifetime 设置为 1 小时 (3600)
• 将 session.gc_probability 设置为 1
• 将 session.gc_divisor 设置为 1
• 因此可以 100% 确定垃圾回收将在 1 小时后对任何空闲 session cookie 进行。

我的问题:

我读过的所有帖子和文档都没有提到将 gc 更改设置为 100%，因此这样做不好吗？有没有更好的办法？

这是一个 symfony 应用程序，从长远来看，我想做这样的事情 http://symfony.com/doc/master/components/http_foundation/session_configuration.html#session-meta-data但现在我希望用 session.gc_* 做一些简单的事情

我读过的一篇文章暗示拥有 100% 的垃圾收集机会是“成本密集型”How do I expire a PHP session after 30 minutes?这是真的？如果是这样， 成本高吗？

干杯!

Answer 1

gc_probability 和 gc_divisor 可让您定义启动垃圾回收 (GC) 的“概率”。

由于 GC(和所有事物一样)是有代价的，您通常不希望它在您的服务器处理的每个 Web 请求上运行 - 这意味着每个页面打开或从 PHP 提供的每个 AJAX 请求都会导致要运行的 GC。

因此，根据实际的服务器负载和使用情况，管理员应该对 GC 运行的频率进行有根据的猜测:100 次、1/10000 次或百万次请求中 1 次。

但是，OP 的原始推理存在一个有问题的缺陷 - 垃圾收集将在任何空闲 session 中发生。我阅读 manual 的方式，垃圾收集将发生在任何 session 上，而不仅仅是空闲 session :

session.gc_maxlifetime integer: specifies the number of seconds after which data will be seen as 'garbage' and potentially cleaned up.

因此， session (空闲与否)的生命周期由 gc_maxlifetime 决定，而 GC 开始的时刻(如文档中所述:“潜在”)由 决定>gc_probability 和 gc_divisor。

继续，我对这个问题的迟到回答是——在正常情况下，我不会在每个请求(你提到的 1/1 场景)上运行 GC，因为

1. 这似乎是一个严重的矫枉过正。在某种程度上，您可能最终会遇到数千个(如果不是更糟的话)IF，并且只有一次进入 THEN
2. 您将在 60 分钟后注销系统上的任何用户，而不仅仅是空闲用户。