incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Schuller <>
Subject Re: what is the expected result of changing this in storage.conf
Date Wed, 04 Aug 2010 17:03:53 GMT
> Thanks for the link but that doesn't answer my question. I happen to know
> quite allot about tuning Linux/Solaris/*NIX. I'm trying to figure out the
> limits in cassandra, when it breaks, and why.
> So, anyone know of or published benchmarks on messing with these values?

In order for such a benchmark to be relevant to you it would have to
very closely match your situation; this feels more about knowing your
access pattern and data than a cassandra issue (unless cassandra is
doing something architecturally wrong/inefficient such that you're
bottlenecking on something "non-legitimate").

For example, if you've got a large data set that go down to disk often
and you're saturating entirely on disk, and your "disk" is a 24 disk
RAID10, then you'll want to scale read concurrency with the amount of
underlying disks (probably 1-2x the amount of disks).

On the other hand if your active working set is effectively in RAM,
you'll probably want to scale with the number of CPU cores.

So your original question of "Do reads at high concurrency get a boost
if I where to raise this value?" will likely depend on several things
specific to your situation, including CPU setup, storage system, data
size, locality of access, working set size, etc.

I suggest benchmarking your particular use-case.

(Not that I wouldn't find it useful to have benchmarks for certain
archetypical cases from which you can then better infer what to expect
in a particular situation.)

/ Peter Schuller

View raw message