当前位置：文江博客话题详情

magento 会话文件需要保存多长时间？

发布于 2024-10-05 14:58:16 字数 181 浏览 3 评论 0原文

我有一位客户的 magento 会话文件正在快速增长并失去控制。我们每周清理一次，但似乎可能需要更频繁。

1）这些文件有什么作用？它们如何与用户的在线体验相关联（例如，如果我删除它们并且用户仍在网站上，它们将受到怎样的影响）

2) 我多久可以删除它们？文件确实需要在服务器上保留多长时间？

克里斯

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

酷到爆炸 2024-10-12 14:58:16

对于基于文件的会话，它们将由 PHP 会话清理 cron 自动修剪 - 因此文件可能会在创建后约 7200 秒内被删除。因此，即使在繁忙的站点（每天 30k 唯一访问量）上，./var/session 中通常也只有大约 4,000 个会话文件——这对于 Linux 服务器来说根本不算什么。

然而，清理实际上依赖于 cron 的工作 - 它通常不会在 Magento 的 ./var/session 目录中查找。所以你应该设置一个新的系统 cron

/usr/bin/find /home/myuser/public_html/var/session -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 -exec rm {} \; >/dev/null 2>&1

会话的默认清理周期是 7200 秒，这应该足够了，尽管你可以更改上面的内容以适应。

对于 Memcache 会话，TCP/IP 是唯一的开销 - 对于单服务器部署来说，这会使其比基于文件的部署慢。那么，您可以使用 unix 套接字来代替，这样可以消除开销并提供更好的安全性。但即便如此，您的客户会话仍将被截断/限制您可以分配的 RAM 量。 Magento 会话的平均大小为 4Kb – 因此您分配的每 MB 可以支持 256 个活动会话。因此，请务必设置适当的限制，以避免客户随机丢失购物车/会话。另请记住，Memcache 守护进程重新启动将清除所有现有会话（糟糕！）。

使用 Redis（不是原生的，但可通过扩展获得），您可以获得与 Memcache 类似级别的支持，但具有持久性的额外好处（如果您希望使用它）。通过 Cm_Redis 扩展，您还可以利用会话压缩。我们发现此扩展在 CE 和 EE 部署上都非常有效。

对于数据库，默认的修剪过期设置为 1 周，因此以上述存储大小为例（每天 30k 个唯一值），您将看到 core_cache_session 的数据库表大小约为 7GB – 这将导致您的商店几乎所有基于会话的操作都完全停止。

根据托管大型（每天 230k 唯一访问者）和小型（每天 <1k 唯一访问者）商店的经验，我们的建议是：

单服务器部署 - 文件

多服务器部署 - Redis (使用与主 Magento 缓存不同的数据库）

我在这里写了一些非常彻底的回复 http://magebase.com/magento-tutorials/magento-session-storage-which-to-choose-and-why/comment-page-1/#comment-1980

With file based sessions, they will be auto-pruned by the PHP session clean-up cron – so the files are likely to be deleted within ~7200 seconds of creation. So even on a busy site (30k uniques per day), there usually only around 4,000 session files in ./var/session – which is nothing for a Linux server.

However, the clean-up actually relies on the cron working - which doesn't normally look in the ./var/session directory of Magento. So you should set up a new system cron

/usr/bin/find /home/myuser/public_html/var/session -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 -exec rm {} \; >/dev/null 2>&1

The default clean up period for sessions is 7200 seconds, which should be more than adequate, although you can change the above to suit.

With Memcache sessions, TCP/IP is the only overhead – which for a single-server deployment, would make it slower than file based. So then, you would use a unix socket instead, which removes that overhead and gives better security. But even still, your customer sessions will be truncated/limited as to the amount of RAM you can allocate. The average Magento session is 4Kb – so you’ll be able to support 256 active sessions, per MB you allocate. So be sure to set an appropriate limit to avoid customers randomly losing cart/session. And also bear in mind, a Memcache daemon restart will wipe out all existing sessions (BAD!).

With Redis (not native, but available via an extension), you get a similar level of support as Memcache, but with the added benefits of persistence (should you wish to use it). With the Cm_Redis extension, you'll also be able to take advantage of session compression. We've found this extension works very well on both CE and EE deployments.

The with DB, the default prune expiration setting is a mighty 1 week, so with the above store size as an example (30k uniques per day), you’ll be looking at a DB table size for core_cache_session of around 7GB – which will grind your store to a complete halt, for almost every session based operation.

From experience of hosting both large (230k unique visitors per day) and small (<1k unique visitors per day) stores, our recommendation is:

Single-server deployment - files

Multi-server deployment - Redis (using a separate database from the main Magento cache)

I wrote some really thorough replies here http://magebase.com/magento-tutorials/magento-session-storage-which-to-choose-and-why/comment-page-1/#comment-1980

回复收藏 0 原文

半衬遮猫 2024-10-12 14:58:16

每个文件都是一个人的会话，并且应该持续时间不超过session.gc_maxlifetime 秒 - 垃圾收集 - 在服务器的 php.ini 文件中设置或在 .htaccess 文件中覆盖。降低此值意味着将累积更少的会话。

Magento 还有另一个关于会话的技巧；在 /app/etc/local.xml 文件中，session_save 值可以更改为 db ，这意味着将使用数据库而不是文件，但是仍然会尊重前面提到的垃圾收集器的生命周期。如果您已设置的话，还可以指定memcache（请参阅/app/etc/local.xml.additional）。如果服务器是集群，两者都非常有用。

回复收藏 0 原文

爱的那么颓废 2024-10-12 14:58:16

取决于您的会话生命周期，如果会话保持用户保持登录状态，或者在再次访问商店时他的首选项保持不变。您可以根据需要经常清除它们，但请记住，在您执行此操作时，它将注销/清除所有登录用户的购物车

回复收藏 0 原文

我的痛♀有谁懂 2024-10-12 14:58:16

不要忘记调查系统的哪个部分在会话中不正确地存储了不合理数量的数据，以实际解决问题。更快地清除会话只是一个临时解决方案。

会话文件应始终保持较小。可能是某些脚本为了“效率”而在会话中存储了过多的数据，从而导致了问题。

几乎可以肯定是会话中存储的对象导致了此问题。 Magento 中的一种常见模式是像这样链接对象数据：

$product->
   'attr1' => 'somevalue',
   ...
   'categories' => array(
       'products' => array(
         <and so on and so forth>
       ),
   ),

将对象放入会话中可能会无意中包含这个巨大的对象链，从而存储大量无关数据。如果可能，请在会话中仅存储字符串/数字数据，例如产品的 ID 数组，而不是产品本身。

Don't forget to look into what part of the system is improperly storing unreasonable amounts of data in the session to actually fix the problem. Clearing sessions sooner is only a temporary fix.

Session files should always remain small. Odds are, some script is storing an inappropriately large amount of data in the session for "efficiency" and causing the problem.

It is almost assuredly objects being stored in the session causing this problem. A common pattern in Magento is to have object data chained like this:

$product->
   'attr1' => 'somevalue',
   ...
   'categories' => array(
       'products' => array(
         <and so on and so forth>
       ),
   ),

Dropping an object into the session can include this gigantic chains of objects unintentionally, storing lots of extraneous data. If possible, store only string/numeric data in the session, such as arrays of IDs for products, rather than the products themselves.

回复收藏 0 原文