How long do the magento session files need to be kept?_问答_开发者

I have a customer who's magento session files are quickly growing out of control. We are purging them once a week, but it seems that it may need to be more frequent.

1) What do these files do? How are they connected to the users online experience (e.g. if I delete them and the user is st开发者_开发知识库ill on the site, how will they be affected)

2) How soon can I delete them? How long do the files really need to remain on the server?

Chris

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

Each file is one person's session and should last no longer than session.gc_maxlifetime seconds - the garbage collection - set in the server's php.ini file or overridden in an .htaccess file. Lowering this value means fewer sessions will accumulate.

Magento has another trick concerning sessions; In the /app/etc/local.xml file the session_save value can be changed to db meaning the database will be used instead of files but will still respect the aforementioned garbage collector lifetime. Also memcache can be specified if you have set that up (see /app/etc/local.xml.additional). Both are very useful if the server is a cluster.

depends on your session lifetime, if the sessions are kept user stays logged in or his preferences stay intact when visiting the store again. You can clear them as often you like but remember that it will log out / clear carts for all users that are logged in while you do it

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.

I also had them piling up so I added a cron job with the following... (this was from instructions in my php.ini file..just under the "session.gc_maxlifetime = 1440" setting)

For example, the following script would is the equivalent of ; setting session.gc_maxlifetime to 1440 (1440 seconds = 24 minutes): ; find /path/to/sessions -cmin +24 | xargs rm