Categories
Tags
apple codex comcast fail fbx gears of war 2 gentoo gitphp got root guitar hero gwu imac interview iphone iphone 3g linksys linux mantis mdb memcached mp3 new york comic con nightwatchman onenightdrunksongwritingexperiment pysoulforge red ring of death resume router school smarty soulforge tom morello towel trick windows work xbox 360 xxcache-
Recent Posts

MDB 0.0.7
As mentioned in my previous post, here is the new version of mdb with caching integrated. There are a few minor bugfixes and adjustments listed in the changelog at the end of the post, but the main bulk of the change is the caching framework. The architecture is described in the other post memcached and smarty in mdb. The framework is set up such that each type of cache is a self contained class, therefore caches can be switched out without changing the rest of the code.
0.0.7 contains three cache types – the memcached class, an eaccelerator class, and an on-disk filecache. I will list the pros/cons of each.
Memcache
Pros: Extremely fast hashtable in memory. Runs as a separate server and is therefore not bounded by the limitations of the webserver. Can be distributed among multiple servers (not implemented in mdb currently, but will be).
Cons: Requires admin rights to get memcached up and running in the first place. Requires an extra daemon to be running.
Eaccelerator
Pros: Has the performance gain of memcached without necessarily requiring a separate server.
Cons: Requires the eaccelerator php extension, which also probably requires admin rights. Has a performance boost but is not as scalable as memcache due to being bound by the limitations of the webserver (tends to be limited as a php extension – cache memory, etc). No gain over filecache if eaccelerator is set to use the disk as cache, instead of shared memory.
Notes: There is a known bug with the eaccelerator cache class right now. Eaccelerator’s shared memory was not really designed to be used as a cache, it was designed to share data between repeated executions of a source file. After updating the database, the cache will not be cleared using eaccelerator, you will have to manually clear the cache by using “cacheflush” on the database page with an admin user. I think it may have to do with the fact that eaccelerator doesn’t work with the commandline php client; I need to find a way around this.
Filecache
Pros: Simple on-disk caching of serialized data. Does not require admin rights to run a daemon or install an extension, just a directory writable by the web server. Simple cache that’s useful if your disk is fast and your database and/or web server is slow.
Cons: Bound heavily by I/O. It will improve execution time by eliminating some of the repeated unnecessary processing, but if your disk is slow to access the cache, then the benefit is eliminated. Also, heavy disk I/O sometimes alerts the admin, which could be a problem if the admin isn’t you.
Notes: To try and avoid heavy disk I/O, you could try having a cache directory that’s mounted as a ramdrive, but setting up a ramdrive usually requires admin rights, in which case you might as well use one of the other solutions. Or you could hope that your server’s /tmp directory is mounted in ram and world-writable.
So, in summation, the memcache is good for scalability (supporting many many clients), performance (speed of page execution), and load (how much I/O or processing is done by the server/database). Eaccelerator cache is good for perfomance and load, as long as eaccelerator is using shared memory for caching. The disk cache is good for performance, and lightens cpu/database load but increases disk load.
Changelog
Get it at the MDB page.