About this linear scaling of throughput(with keys perfectly distributed + requests balanced over all nodes): I would assume that this is not the case for small number of nodes because starting from 2 nodes onwards a part of the requests have to be handled by a proxy node + the actual node responsible for the key. Is there no other overhead that starts to play when increasing the number of nodes? Until now we were not able to reproduce this linearly scaling of throughput. We are still figuring out why but it would be interesting to know what the target should be...
-David On Wed, May 12, 2010 at 4:13 AM, Paul Prescod <p...@prescod.net> wrote: > On Tue, May 11, 2010 at 5:56 PM, Mark Greene <green...@gmail.com> wrote: > > I was under the impression from what I've seen talked about on this list > > (perhaps I'm wrong here) that given the write throughput of one node in a > > cluster (again assuming each node has a given throughput and the same > > config) that you would simply multiply that throughput by the number of > > nodes you had, giving you the total throughput for the entire ring (like > you > > said this is somewhat artificial). The main benefit being that adding > > capacity was as simple as adding more nodes to the ring with no > degradation. > > So by your math, 100 nodes with each node getting 5k wps, I would assume > the > > total capacity is 500k wps. But perhaps I've misunderstood some key > > concepts. Still a novice myself ;-) > > If the replication factor is 2, then everything is written twice. So > your throughput is cut in half. > > Paul Prescod >
