Tutorial - miscellaneous
Security
Scache is generally assumed to be used by trusted client. Clients are assumed to control what to store and do necessary checks to not let data be uncontrollably pass-through passed from browsers to backend. By partitioning, it is possible to some level control resources consumption, but responsibility from controlling what to store and what to not, must be on php code sitting between and accessing scached.
Until declared to version 1.0 scached probably contains bugs, might crash or at least there exists issues in memory tracking due to complexity in internal memory management.
Main issue to take into consideration is memory consumption. Scached expects to have enough memory to store all you want to store to it. As it is many times mentioned, scache is no cache that has privilege to forget something when needed. Scached doesn't even try to handle out of memory situations, instead it expects connecting clients to control that it cannot be flooded full and out of business.
Of course memory doesn't need to be RAM. Scached expect enough virtual memory, so just make sure that there is enough swap space available to be overflown onto. In addition to stored key length and data length scached consumes some extra 50 bytes for every stored node plus some 500 bytes per session. Scache is actually quite memory efficient, so there could be stored quite a lot of data until you hit on problems.
But with web application you need always to take concern of hostile activity, for example someone flooding hundreds of thousands of sessions. In this case scached process can grow to enormous sizes, but on the another hand, swap space is where it goes. So keep up enough swap space if you expect problems, disk space is cheap nowadays.
Don't take above wrong. If you are not running some hobby like small scale or even larger project there is no problems with memory. To start scached it takes some couple hundred kilobytes and to get it to take couple megabytes you need lots of concurrent browser sessions or carelessly done querier. Scached fits just well especially to small installations.
Memory reminders above are just reminders that you need to keep it in your mind.
Partition or not to partition
With partitioning you can divide one scached to multiple resource pools. You can assign clients to different partition either by host based or by php.ini defined auth strings.
Every partition has independent shared keyspaces so data stored to one cache or shared storage is not available to clients assigned to other partitions. Every partition also has its own limits on cache and storage memory consumption.
On another hand, partitions are shared by single process. If process crashes, all its partitions are gone.
Another way is to run multiple scacheds. Prebuild binaries' init scripts support that option as long as you remember to specify different ports and socket paths for every individual scached.conf.
Running multiple scacheds is more secure and reliable solution, but as drawback while partitioned scached efficiently reuses memory nodes freed by its internal partitions, separate processes dont. Memory in separate processes is even probably so scattered that it is not easily swapped out by system.
Shared keyspace vs. sharing session
Shared keyspace is bit overlapping feature. Same could be achieved by sharing some well-known session in addition to those private sessions.
$shared = scache_open('OurCommonStorage');
$private = scache_open($_COOKIES['MySessionID']);
Nothing prevents for having multiple sessions open simultaneously as long as you remember to set long enough session timeout for that "shared" session opened for common use. While data stored on shared keyspace does not ever expire, private sessions do.
scache_sh* -functions are just easy, faster and simpler way for the most common usages than keeping up multiple connections. But there might be sensible scenarios where best way is just keep multiple sessions open.