<br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Ultimately your performance is governed by the speed of your disks, how<br>many indicies you have on your tables and how long you buffer your
<br>writes before syncing to disk. My replication cluster was operating<br>close to 1000 qps with round robin reads across two replication slaves.<br>My ratios on the master are like 41/10/17/0 and the replicants are like
<br>68/14/10/0.<br><br>By converting about five of my most popular php scripts, I've easily cut<br>it down 30%.I find that replication lag is reduced because I'm cutting<br>down the number of queries on the replicants. If I keep spreading
<br>memcache to the rest of my php pages (as appropriate) I easily expect to<br>cut down 60% of my selects. I think that 300qps with 30/30/30/0 ratios<br>or better is easily possible for my mysql replication cluster. So my
<br>limit is roughly converging to "how many writes I can push" into a table.</blockquote><div><br>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.
<br></div><br></div>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.<br><br>Kevin<br clear="all"><br>-- <br>Founder/CEO <a href="http://Tailrank.com">
Tailrank.com</a><br>Location: San Francisco, CA<br>AIM/YIM: sfburtonator<br>Skype: burtonator<br>Blog: <a href="http://feedblog.org">feedblog.org</a><br>Cell: 415-637-8078