※ 引述《gpmm (银色)》之铭言： : : → TonyQ:反过来了吧，大多是从记忆体挪进 disk，避免记忆体爆量吧 05/15 20:50 : : → gpmm:楼上说的是 session 吗？ XD 05/15 21:36 : 其实这比较是一个依需求判定的情形，如果每支 session 都超持久外加内容超多， : 那的确是有可能会撑爆记忆体，尤其像 PHP 的 session 回收机制其实有很大漏洞。 : 在以前经验里，日 pv 五百万上下，session timeout 一小时起跳（对， : 我们家 session timeout 预设值我记得有调高到三小时过）的服务平台， : 前面四台 www + 後面一台跑 4G mmc 的主机挂 session 应付是非常绰绰有余， : 但如果在同样情况下改作 db session 就有可能撞上讨厌的 connection battle， : 不过说起来这毕竟也只是某个环境而已， : T 大您也可以分享一下您的经验 :DD 因为你原文是写 session 需要的话可以放到 memory ， 但根据我的经验是反过来， session 一般是放 memory ，需要时才转 io 或 db。 这也有可能是语言或平台的差异啦， 但是据我所知，asp/javaee/asp.net 应该都是预设放记忆体才对。 基本上各 container 的 default session 实作，应该都是 in memory 的吧， 除了像 php 的 CI 之类的 framework 层有自己想法自己包 db session。 还有一个特例是 cluster 环境下，实作时也会特别把 session 弄成可以 IO。 预设会是 in memory 是有理由的， 你要能 IO 的东西势必要是能 serializable (可序列化)的。 可序列化意味着可以进行 IO 操作，写入档案里面跟还原回来。 也就是说，如果是你放的是 string/int ..etc 这类基本型态就算了， 基本型态通常都会是可序列化的。 但如果今天你放的是 custom class 的 instance ， 他存进去後还能不能安全照你想的方式捞回来，那就是另一回事了。 当然有些语言「可能」不用烦恼这些问题，（语言特性或限制就处理掉了） 但是在很多地方，这些还是讨厌的事情。 另外，这个问题要看你把多少东西塞 session ， 我前公司的产品在 session 每个人就可以到几 mb ，（有特别需求） 就不见得一定能这样玩了。XD 我只是在说明「预设」跟「常见」的状况啦， 当然每个专案还会因为每个专案的需求调配跟调整罗。 -- Life's a struggle but beautiful. --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 114.25.110.147 ※ 编辑: TonyQ 来自: 114.25.110.147 (05/15 22:25) ※ 编辑: TonyQ 来自: 114.25.110.147 (05/15 23:22)