A Redis-backed PHP session handler with optimistic locking
OTHER License
BREAK_AFTER
seconds and the process that gets the lock is indeterminate.MAX_CONCURRENCY
processes may be waiting for a lock for the same session or else a ConcurrentConnectionsExceededException will be thrown.Session data compresses very well so using compression is a great way to increase your capacity without
dedicating a ton of RAM to Redis and reducing network utilization.
The default compression threshold
is 2048 bytes so any session data equal to or larger than this size
will be compressed with the chosen compression_lib
which is gzip
by default. Compression can be disabled by setting the compression_lib
to none
. However, both lzf
and
snappy
offer much faster compression with comparable compression ratios so I definitely recommend using
one of these if you have root. lzf is easy to install via pecl:
sudo pecl install lzf
NOTE: If using suhosin with session data encryption enabled (default is suhosin.session.encrypt=on
), two things:
If any compression lib fails to compress the session data an error will be logged in system.log
and the
session will still be saved without compression. If you have suhosin.session.encrypt=on
I would either
recommend disabling it (unless you are on a shared host since Magento does it's own session validation already)
or disable compression or at least don't use lzf with encryption enabled.
Bots and crawlers typically do not use cookies which means you may be storing thousands of sessions that serve no purpose. Even worse, an attacker could use your limited session storage against you by flooding your backend, thereby causing your legitimate sessions to get evicted. However, you don't want to misidentify a user as a bot and kill their session unintentionally. This module uses both a regex as well as a counter on the number of writes against the session to determine the session lifetime.
Using Cm_RedisSession alongside Cm_Cache_Backend_Redis should be no problem at all. However, it is strongly advised to run two separate Redis instances even if they are running on the same server. Running two instances will actually perform better since Redis is single-threaded so on a multi-core server is bound by the performance of a single core. Also it makes sense to allocate varying amounts of memory to cache and sessions and to enforce different "maxmemory" policies. If you absolutely must run one Redis instance for both then just don't use the same 'db' number. But again, just run two Redis instances.
@copyright Copyright (c) 2013 Colin Mollenhour (http://colin.mollenhour.com)
This project is licensed under the "New BSD" license (see source).