PEAR::Cache : Shared Memory Container

From: 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

« previous php.pear.dev (#1417) next »