What is the PHP Shared Memory (mm, --with-mm) session module?

Question

What is the PHP Shared Memory Allocation (mm, compiled --with-mm) session module?

Have you used it? Have you tested it? Does it work good? Did you have session locking problems?

It's easy to view the contents of your session data when using files or a custom session handler (like a database), but is it possible to view the session data with this module? Personal reasons for wanting to view the session data would be to (1) test PHP garbage collection is working properly and (2) make sure it isn't hogging all the system memory.

I think it used to be a separate (PECL? Zend?) extension, but now it's in core.

The only requirement to compile it into the PHP binary are the OSSP mm headers, which is a small ~330k download.

 $ ./configure --help

// --with-mm=DIR   SESSION: Include mm support for session storage

The only info I could find was from a message board post in 2006 referencing a now-missing Zend session tutorial page [404], from which the author quoted:

If you need higher performance, the mm module is a viable alternative; it stores the data in shared memory and is therefore not limited by the hardware I/O system.

I understand two of it's limitations:

(1) Note that the session storage module for mm does not guarantee that concurrent accesses to the same session are properly locked. It might be more appropriate to use a shared memory based filesystem (such as tmpfs on Solaris/Linux, or /dev/md on BSD) to store sessions in files, because they are properly locked. (2) Session data is stored in memory thus web server restart deletes it.

I'd really like a canonical description, but any and all info is appreciated.

Answer 1

I have not used shared memory with sessions but I have been using https://www.php.net/manual/en/book.shmop.php lately which seems to be what is used for sessions.

The awesome thing with shared memory is that it's a crazy fast way of sharing data between processes. The price for that is that since you are just storing directly in memory there is no control on who is writing when (and it not persistent). Using a file sessions in a memory file system fixes this be adding the filesystem layer on top (REDIS and memcached also handles this).

If you write a lot to your sessions and have a reasonable chance of having two request running at the same time you will get unexpected data at some point. Whatever that is a problem is matter of how much you need to rely on your session data.

If you write only once and then it's all read after that, like storing a user id at login, then it should work just great.

In regards to GC, there should be no difference between session modules.