[Plugin: DB Cache Reloaded] Performance question

  • Alexander Gieg

    (@alexgieg)


    14 years, 2 months ago

    After mentioning this plugin on my host’s support forum as an alternative to other caching plugins. This is how I described it:

    “I use DB Cache Reloaded. It has quite a different approach compared to other caching plugins, placing itself between WP and MySQL and storing in the filesystem, for a short period (5 min default), answers to database queries.”

    However, the sysadmin (the one who manages the whole server farm) replied thus:

    This will destroy your blog’s performance at any kind of high traffic level. The filesystem is the slowest resource PHP can address.

    For lots of reasons I trust his advices as I know he really knows his stuff, and if he says on his system filesystem access is way slower than direct MySQL-access, this is certainly true.

    However, his advice is based on my description of how DB Cache Reloaded works, which I’m not quite sure is a precise description at that. So, I’d like to know whether what I described is accurate.

    I mean, when a DB Cache Reloaded-enabled WordPress blog renders a page, does DB Cache Reloaded read the cached queries from the cache folder, by direct file operations (open/read/close, open/read/close, open/read/close…), one set of file operations for each query? Or does it use some other mechanism that doesn’t involve multiple such filesystem accesses?

    I’d love to continue using DB Cache Reloaded in this host, but for that I need to know a little more about its inner working to ask my sysadmin whether it’s efficient or not in his system. If he still says it isn’t, I’ll have to unfortunately switch to a more traditional full-page caching solution. 🙁

    Thank you!

    http://wordpress.org/extend/plugins/db-cache-reloaded/

Viewing 3 replies - 1 through 3 (of 3 total)
  • Thread Starter Alexander Gieg

    (@alexgieg)

    14 years, 2 months ago

    After asking a few more questions, I received more information from my sysadmin:

    It is a problem with open_basedir and concurrency.

    We handle heavy hits on a default WordPress install. Plugin choice, caching and other, however, is everything.

    Caching plugins that turn otherwise-dynamic requests into static, cacheable ones suitable for reuse do well. All other kinds, particularly ones that convert MySQL queries to filesystem queries, do poorly.

    Well, this means that no matter how DB Cache Reloaded works internally, there’s no hope of using it meaningfully at his host, at least for as long as they’re running PHP in safe_mode. When/if they drop safe_mode I’ll look into using DB Cache Reloaded again. Thanks!

    tommix

    (@tommix)

    14 years, 2 months ago

    Database is also on disk-so database too reads/writs to file on disk 🙂

    And you should ask-what is heavy load..how many people online. Cause i can bet more chances to hang server because of DB queries than hdd I/O operations. This also reduces CPU load.

    Thread Starter Alexander Gieg

    (@alexgieg)

    14 years, 1 month ago

    Sure, but what happens is that it’s a very security-focused hosting service, so they enable features that make the service more secure even if it causes slower performance on specific cases. In this case, the problem is a bug in how PHP handles open_basedir that causes concurrent disk accesses to clash with each-other slowing down all file-access processes that are trying to read the same file. Since disabling open_basedir would cause PHP to become less secure, and the PHP folks aren’t solving the issue (they’re discontinuing safe_mode in PHP 6 anyway, so they don’t bother), the result is the need for workarounds. The workaround is thus to not cache database accesses in disk, but let them go straight to the MySQL server, as MySQL doesn’t suffer from concurrent access clashes.

    As for MySQL bringing down a server, well, they don’t keep MySQL and PHP running on the same machines. There are PHP servers and independent MySQL servers, so that a bug on one that perchance were exploited by a hacker cannot be used to compromise the other. Every database access is done over the internal network. And the MySQL servers are beefed up to resist even slashdotings and first-page diggs. BugMeNot, for instance, is hosted with them.

    As you can see, the problem they point is very specific to their setup. I’m sure on more standard hosts DB Cache Reloaded works marvelously. It’s only that in this specific host (and those few others with open_basedir restrictions enabled) it might cause problems.

    As for what heavy load means, if I’m not mistaken it means a few hundred simultaneous accesses to the same files, thus something most sites woun’t feel most of the time, but that would certainly cause them to stop working in case of a slashdotting/digging.

    I hope this helps. For whatever it’s worth, I’m currently using W3 Total Cache, but with its own DB caching disabled, and only its file caching enabled.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘[Plugin: DB Cache Reloaded] Performance question’ is closed to new replies.