2010-12-04 113 views
7

我有一個客戶誰magento會話文件正在迅速失控。我們每週清除一次,但似乎可能需要更頻繁。magento會話文件需要保存多久?

1)這些文件有什麼作用?他們如何連接到用戶的在線體驗(例如,如果我刪除他們,用戶仍然在網站上,他們將如何受到影響)

2)多久可以刪除它們?文件真的需要保留在服務器上多長時間?

克里斯

回答

7

每個文件是一個人的會議,並應該所有用戶過去的不超過session.gc_maxlifetime秒 - 垃圾收集 - 在服務器的php.ini文件中設置或在.htaccess文件中重寫。降低此值意味着更少的會話會累積。

Magento有關於會話的另一個技巧;在/app/etc/local.xml文件中,session_save值可以更改爲db,這意味着將使用數據庫而不是文件,但仍將遵守上述垃圾回收器生存期。如果您已經設置了該參數,則還可以指定memcache(請參見/app/etc/local.xml.additional)。如果服務器是集羣,則兩者都非常有用。

+0

使用數據庫進行會話管理還有其他好處嗎?我通常使用文件系統(我相信這是默認)。 – Chris 2010-12-04 18:25:14

+0

數據庫存儲的會話將更容易備份。如果數據庫是一個單獨的服務器,它將減少主服務器HDD上的工作量,但如果您擔心這種情況,也可以將會話文件夾掛載爲tmpfs。與文件不同,隨着會話數量的增加,數據庫不會使用文件句柄,文件系統對其可容納的文件數量有限制,而繁忙的服務器可能會超過該限制。數據庫也可能透明地壓縮它的表,這也會減少空間需求。 – clockworkgeek 2010-12-04 18:49:12

+0

我建議不要使用memcache來存儲會話,因爲Magento緩存刷新memcache是​​全部或全無 - 這意味着當您刷新緩存時,您將終止客戶會話。 Memcache非常適合magento,但不是會話。 – 2010-12-05 01:53:19

2

取決於你的會話有效期,如果會話保持用戶停留登錄或再次逛店時,他的喜好保持不變。你可以經常你喜歡清除它們,但請記住,它會退出/清除推車中記錄的,而你做到這一點

2

不要忘記查看系統的哪個部分在會話中不正確地存儲不合理的數據量,以便真正解決問題。儘快結算會議只是一個臨時的解決方案。

會話文件應始終保持較小。可能性是,某些腳本會在會話中存儲不適當的大量數據以提高效率並導致問題。


幾乎可以肯定的是,存儲在會話中的對象導致了這個問題。在Magento一個常見的模式是有鏈接這樣的對象數據:

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

刪除一個對象到會話可以包括對象的這個巨大的鏈無意地存儲大量無關數據。如果可能,只在會話中存儲字符串/數字數據,例如產品ID的數組,而不是產品本身。

9

使用基於文件的會話時,它們將被PHP會話清理cron自動修剪 - 所以這些文件很可能會在〜7200秒內被刪除。所以即使在一個繁忙的網站(每天3萬個唯一身份)中,通常只有大約4,000個./var/session中的會話文件 - 這對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 - 因此您可以支持256個活動會話,每個分配的MB。所以一定要設定適當的限制,以避免客戶隨機丟失購物車/會話。還要記住,Memcache守護進程重啓將消除所有現有會話(BAD!)。

使用Redis(不是本機的,但通過擴展可用),您獲得與Memcache類似的支持級別,但具有持久性(如果您希望使用它)的附加好處。通過Cm_Redis擴展,您還可以利用會話壓縮。我們發現這個擴展在CE和EE部署上都非常好。

帶數據庫,默認的剪枝過期設置是一個強大的1周,所以以上面的商店大小爲例(每天30k獨特),你將看到一個大約7GB的core_cache_session數據庫表大小 - 幾乎每個基於會話的操作都會使您的商店癱瘓。

從託管既有大(每天< 1K獨立訪客)(230K獨特的每日訪客)和小商店的經驗,我們的建議是:

單服務器部署 - 文件

多-server部署 - Redis的(使用從主Magento的高速緩存單獨的數據庫)

我這裏寫一些真正徹底的答覆http://magebase.com/magento-tutorials/magento-session-storage-which-to-choose-and-why/comment-page-1/#comment-1980

0

我也有他們堆積,所以我添加了一個cron工作與以下...(這是從我的php.ini文件中的說明..只是在「session.gc_maxlifetime = 1440」設置下)

For例如,以下腳本將等於 ;將session.gc_maxlifetime設置爲1440(1440秒= 24分鐘): ; find/path/to/sessions -cmin +24 | xargs rm