As mentioned in this post, there is a bug in MDB <= 0.0.7 that inhibits downloading of files larger than your output buffer’s size (usually 128M), which makes file downloads particularly useless in an app like this that was originally designed to archive tv/anime show episodes that are usually over that size.  I don’t foresee my schedule letting me get much work done on MDB so as I promised, I’ve released a new version of MDB with that fixed.  Get it on the mdb page.

MDB has a bug inhibiting downloading of files larger than a certain size.  Output buffering was accidentally left on during file download, so files larger than the output buffer (usually 128M) are truncated to that size.  The one little fix is a bit too small for a whole release right now, so I’ll either have to wait to do more fixes or until a little time has passed and I feel that no other fixes will be coming.  Either way, the fix is in gitphp so if it’s a problem you can grab the snapshot.

Codex is currently getting the same massive revamp, feature boost, and cache framework that MDB got.  It’s my oldest full fledged PHP/SQL project so it has the crappiest code and could benefit the most from such a thing.

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

• Strip out non-alphanumeric characters when adding tags – preventing tags such as “genderbending” and “gender bending” being treated as two different tags
• Exclude ext3′s “lost+found” directory by default
• The dbcheck page now scans for files that are in the database but no longer exist on disk
• Persistent connections disabled by default
• Debugging no longer interferes with file downloads
• When loading a title’s page, list of titles on the right will automatically open to the correct letter
• Apply smarty’s trimwritespace filter to all templates
• Organizational cleanup
• Cache framework, including cache stats on the dbstats page, cache info in the footer (type/hits/misses), and an option on the db management page to flush cache
• Memcached cache type
• Eaccelerator cache type
• File cache type

Get it at the MDB page.