Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (athena.apache.org: domain of
 gcdcu-cassandra-user-1@m.gmane.org designates 80.91.229.12 as permitted
 sender)
To: user@cassandra.apache.org
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: writes to Cassandra failing occasionally
Date: Fri, 09 Apr 2010 09:25:57 -0500
Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @
 Cienfuegos
Lines: 20
Message-ID: <87wrwgr9ca.fsf@lifelogs.com>
References: <4BBCE8CE.9000805@gmail.com> <87k4sit7nj.fsf@lifelogs.com>
	<4BBE257E.3070207@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux)
Cancel-Lock: sha1:3c4pXZTC6AHSU6htVO0QEg4FeJc=

On Thu, 08 Apr 2010 11:50:38 -0700 Mike Gallamore <mike.e.gallamore@googlemail.com> wrote: 

MG> Yes I agree single threaded is probably not the best. I wonder how
MG> much of a performance hit it is on a single CPU machine though? I
MG> guess I still would be blocking on ram writes but isn't like there is
MG> multiple CPUs I need to keep busy or anything.

Cassandra may have to load data from disk for a particular query but
another may already be in memory.  A third may cause a hit on another
cluster node.  So if you issue queries serially you'll see performance
drop off with the total number of queries because they are dependent on
each other's performance, while the distribution of the performance of
independent parallel queries will have skew and kurtosis much closer to
a normal distribution.  In other words, your slowest (or unluckiest)
queries are less damaging when you issue them in parallel.

On the client side you still have slow serialization/deserialization and
not much can be done about that.

Ted