※ 引述《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)