Ben*_*ssi 10
使用基于文件的会话,它们将由PHP会话清理cron自动修剪 - 因此文件很可能在创建后约7200秒内被删除.因此,即使在繁忙的站点(每天30k uniques),在./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
Run Code Online (Sandbox Code Playgroud)
会话的默认清理时间是7200秒,这应该是足够的,尽管您可以更改上述内容以适应.
使用Memcache会话时,TCP/IP是唯一的开销 - 对于单服务器部署而言,它会比基于文件的速度慢.那么,您将使用unix套接字,这将消除该开销并提供更好的安全性.但即便如此,您的客户会话将被截断/限制您可以分配的RAM量.平均Magento会话是4Kb - 因此您将能够支持256个活动会话,每MB您分配.因此,请务必设置适当的限制,以避免客户随意丢失购物车/会话.还要记住,Memcache守护进程重启将消灭所有现有会话(坏!).
使用Redis(不是原生的,但通过扩展可用),您获得与Memcache类似的支持级别,但具有持久性的额外好处(如果您希望使用它).使用Cm_Redis扩展,您还可以利用会话压缩.我们发现这个扩展在CE和EE部署上都能很好地工作.
使用DB,默认的剪枝过期设置是一个强大的1周,所以以上面的商店大小为例(每天30k uniques),你将看到一个大约7GB的core_cache_session的数据库表大小 - 这将研磨您的商店完全停止,几乎每个基于会话的操作.
根据拥有大型(每天230k独立访客)和小型(每天<1k独立访客)商店的经验,我们的建议是:
单服务器部署 - 文件
多服务器部署 - Redis(使用主Magento缓存中的单独数据库)
我在这里写了一些非常详尽的回复http://magebase.com/magento-tutorials/magento-session-storage-which-to-choose-and-why/comment-page-1/#comment-1980
每个文件都是一个人的会话,并且应该持续不超过session.gc_maxlifetime秒 - 垃圾收集 - 在服务器的php.ini文件中设置或在.htaccess文件中重写.降低此值意味着将累积更少的会话.
Magento还有另一个关于会话的技巧; 在/app/etc/local.xml文件中,session_save值可以更改为db意味着将使用数据库而不是文件,但仍将遵守上述垃圾收集器生命周期.memcache如果你设置了它也可以指定(见/app/etc/local.xml.additional).如果服务器是集群,则两者都非常有用.
| 归档时间: |
|
| 查看次数: |
15839 次 |
| 最近记录: |