MySQL cluster vs memcached
burton at tailrank.com
Fri Oct 13 23:48:04 UTC 2006
> Ultimately your performance is governed by the speed of your disks, how
> many indicies you have on your tables and how long you buffer your
> writes before syncing to disk. My replication cluster was operating
> close to 1000 qps with round robin reads across two replication slaves.
> My ratios on the master are like 41/10/17/0 and the replicants are like
> By converting about five of my most popular php scripts, I've easily cut
> it down 30%.I find that replication lag is reduced because I'm cutting
> down the number of queries on the replicants. If I keep spreading
> memcache to the rest of my php pages (as appropriate) I easily expect to
> cut down 60% of my selects. I think that 300qps with 30/30/30/0 ratios
> or better is easily possible for my mysql replication cluster. So my
> limit is roughly converging to "how many writes I can push" into a table.
I'd prefer to NOT have disk involved......... I'm curious if you could in
theory use NDB as a replacement for memcached... there would be no LRU
semantics of course.
With 5.1 and disk support you can at least have larger DBs and just add more
machines to your cluster if you need more throughput.
Location: San Francisco, CA
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the memcached