设置session.gc_probability和session.gc_divisor等于100%是个坏主意吗？

Question

场景:

我怎么想我能解决这个问题:

我的问题:

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

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

我读过的一篇文章暗示拥有100%垃圾收集机会是"成本密集型" 如何在30分钟后使PHP会话到期？这是真的？如果是这样,如何成本密集？

干杯!

Answer 1

该gc_probability和gc_divisor在那里让你定义发射了垃圾回收（GC）的“概率”。

由于 GC（作为一切）是有成本的，您通常不希望它在您的服务器处理的每个 Web 请求上运行 - 这意味着每个页面打开或从 PHP 提供的每个 AJAX 请求都会导致 GC跑。

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

但是，OP 的原始推理中存在一个有问题的缺陷 - that garbage collection will occur on any idle session. 我阅读手册的方式，垃圾收集将发生在任何会话上，而不仅仅是空闲会话：

session.gc_maxlifetime integer:指定数据将被视为“垃圾”并可能被清理的秒数。

因此，会话（空闲与否）的生命周期由决定gc_maxlifetime，而 GC 开始的时刻（如文档中所述：“可能”）实际上是由gc_probability和决定的gc_divisor。

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

假设你的概率是 1/1000。您每天、每小时或每分钟可能有 1000 次点击。因此，根据网站负载，您的 GC 可能每天、每小时或每分钟启动一次。每当它运行时，它都会杀死所有超过 60 分钟的会话（因为 `gc_maxlifetime` 不仅涉及 **空闲** 会话，还涉及所有会话）。 (2认同)

Answer 2

有很多更好的方法可以做到这一点。

如果这不是为了特别安全，您可以在客户端设置会话 cookie 的到期日期/长度。在这种情况下，有技术头脑的用户可以调整过期时间，因此您不会想在银行网站上使用它。

如果您需要更安全的东西，只需将过期时间与其他会话数据一起存储并进行检查即可。如果超出，则销毁他们的会话并强制他们重新登录。