Slashdot's main shard runs on 4 DBs, 2 of which are identical read-only slaves running MySQL 5.0.51a. All our tables are InnoDB.
On Saturday I reconfigured one of them to remove its query cache, repointed our backend processing so the only thing hitting these slaves was the webheads, and restarted them both at the same time, to test whether and how much the query cache improves efficiency. Cacti graphs for Sunday-Monday are here: <http://lvalue.com/qc-vs-noqc/> The humps on the right side are where traffic picked up at 9 AM EDT. Slashdot's caching is kind of ad-hoc, but we do cache (memcached and local cache) a lot of the easy and big and frequently-used objects, probably more than most sites. It could be better, but it's not bad. If anything, I think taking us as a typical access pattern would be optimistic. Our query cache hit rate is ~60%. Removing the cache increases row reads by 2200%, table scans by 2300%, table locks by 60%, temp tables by 300%, and the extra work doubles CPU usage. I don't know how much performance Drizzle gains by removing the query cache, but it'd have to be a lot for Slashdot to come out ahead. -- Jamie McCarthy http://mccarthy.vg/ [EMAIL PROTECTED] _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
