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.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
