PEAR::Cache : Shared Memory Container
| From: | Ulf Wendel | Date: | Mon, 13 Aug 2001 08:54:53 +0000 |
| Subject: | PEAR::Cache : Shared Memory Container | ||
| Groups: | php.pear.dev | ||
| Request: | Send a blank email to pear-dev+get-1417@lists.php.net to get a copy of this message | ||
Hi there,
I've implemented a simple, straight forward shm container using
semaphores and shmop_* functions for the PEAR cache system. Features and
performance are quite poor. Maybe it's a starting point for someone of
you to find a better implementation. I doubt that one can find a really
cool way to implement it - PHP was not made to use SHM efficiently...
A "good" container would eighter waste lot's of shared memory keys with
the danger of clashes or need to rebuild a simple memory manager,
possibly using first fit for a fast solution. I've done some basic case
studies for both ways with disappointing results: complicated and slow.
The current implementation uses one shared memory segment and one
semaphore. The default size of the shm segment is about 131.000 bytes, a
typical max size on (older) unix systems. This means that the container
can't store more than this bytes at once, so it's no good idea to use it
for something else but a SQL or function result cache. The semaphore is
used for syncronizing. Only one process can access (read and write) the
shm segment at once. Removing the locking does not increase the
performance notably nor does reducing the default shm segment size.
Speed: about 1/4 - 1/3 of the file container according to some very
simple tests. Remember that your OS usually caches files which means
that files get severed out of your disk cache. This means that the file
container is the container of choice in case you have one webserver and
db(x) if you have multiple ones.
Have fun!
Ulf