Re: Very high speed session management -- help me test

Mark wrote:

Jochem Maas wrote:

....

That's sort of the problem with names, it is hard to convey ideas. MCache (formally msession) has a history. I originally wrote the code as a way to

there is a php extension called 'mcache' with is a wrapper for memcache - but this is not the same as your tool right? in which case I doubly recommend another name :-)

share data for a beowulf cluster. Later on I was working on a site that had

the words 'cluster' may very well be something to think about .. e.g. 'ClusterCache'

multiple PHP web servers and realized it was the exact same problem domain. Multiple machines at any one instant mostly working on different data but requiring access to serialized shared data or a central store of data. This is a HUGE problem once you get past one PHP server. Even with one server you still need a database to manage your poll. You can't do this: $var = sql->exec("select poll_count from poles where pollid='foo' and name='bar'"; $var++; $var = sql->exec("update poles set poll_count = $var where pollid='foo' and name='bar'"; In an active site you will have concurrency issues and lose counts even on a single machine. So you'll have to do something like this: sql->exec("update polls set poll_count = poll_count+1 where pollid='foo' and name='bar'"; $var = sql->exec("select poll_count from poles where pollid='foo' and name='bar'"; That is *always* two database operations. Best not get slashdotted! With MCache, it works like this: $var = mcache_inc("foo','bar');

that is nice... :-)

Now, depending on your strategy, there will may be no hits your database or (at most) one. How many times have you seen a site DOA because the database (typically MySQL) has crapped out? MCache on a modern computer, handling the session storage and retrieval, and a one or two variable calls like the above, can handle (depending on session size, network speed, etc.) upwards of 5000 operations a second. It is designed to be fast!!! Granted, if the session information is larger than one TCP/IP packet, it is slower, but still way faster than a database.

I just checked some session file sizes on a 'heavy' site I built. the largest file was 332607 bytes; which very roughly speaking would require about 220 packets. is such a large session file feasible with you tool? (regardless of whether one might suggest that I have a design flaw in the site in question)

is this better than using the 'files' session handler and setting the session save path to a tmpfs filesystem (in effect a RAM disk) in a signle server env.?

This is not really intended for a single server site, but could provide some benefit as a way of abstracting file or SQL session storage.

ok; although that doesn't answer my question. another thing if it's not really intended for a signle server site then youre audience here is rather limited - I'm guessing that there are not many here running distributed/load-balanced systems. I don't atm; but it almost makes me want to go out and get a server to try it out.

Well, using the poll operation detailed above, you can see relative advantages. It is faster than the PHP file based sessions. It can periodically save session data. It does its own garbage collection. It can be used to call external functions. It will eventually (there now, needs testing and debugging) even have a SQL based write through caching plug-in that will allow an amount of database abstraction, or even session storage abstraction.

I for one will definitely be watching your space :-)

the word out and get some testers. The server itself is GPL, the PHP extension is under the PHP license. I will be checking it in to the PHP main CVS repository when I'm pretty sure that it will play nice. The server can be accessed via CVS from www.mohawksoft.org. If you have any questions please feel free to ask.