incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Tryuber <stryu...@gmail.com>
Subject Re: Read latency issue
Date Wed, 03 Oct 2012 14:33:14 GMT
Hi Arindam,

Just want to share our experience about latency. We use Cassandra to read
all columns for a specified key (5-10 columns, 10-15 each, no composites).
All our dataset fits memory (40GB on each node) and we use
LeveledCompactionStrategy. Our RF=2 and we read with CL=ONE. Also we use
Astyanax, which allows us to connect to that Cassandra node, which holds
data local (no additional network hops). The best performance we got is
with disabled row and key caches (no additional GC pressure) and reduced
heap size to 3.5GB. Our average read latency is 2ms, 99% fit in 10ms (1K
writes/updates/deletes and 1K reads per Cassandra node per second).


On 3 October 2012 11:32, aaron morton <aaron@thelastpickle.com> wrote:

> > Running a query to like “select * from <table_name> where atag=<foo>”,
> where ‘atag’ is the first column of the composite key, from either JDBC or
> Hector (equivalent code), results in read times of 200-300ms from a remote
> host on the same network.
>
> If you send a query to select columns from a row and do not fully specify
> the row key cassandra has to do a row scan.
>
> If you want fast performance specify the full row key.
>
> > Using read consistency of ONE reduces the read latency by ~20ms,
> compared to using QUORUM.
> It would only have read from the local node. (I think, may be confusing
> secondary index reads here).
>
> Cheers
>
> -----------------
> Aaron Morton
> Freelance Developer
> @aaronmorton
> http://www.thelastpickle.com
>
> On 3/10/2012, at 2:17 AM, Roshni Rajagopal <roshni_rajagopal@hotmail.com>
> wrote:
>
> > Arindam,
> >
> >   Did you also try the cassandra stress tool & compare results?
> >
> > I havent done a performance test as yet, the only ones published on the
> internet are of YCSB on an older version of apache cassandra, and it
> doesn't seem to be actively supported or updated
> > http://www.brianfrankcooper.net/pubs/ycsb-v4.pdf.
> >
> > The numbers you have sound very low, for a read of a row by key which
> should have been the fastest.  I hope someone can help investigate or share
> numbers from their tests.
> >
> >
> >
> > Regards,
> > Roshni
> >
> >
> > > From: Dean.Hiller@nrel.gov
> > > To: user@cassandra.apache.org
> > > Date: Tue, 2 Oct 2012 06:41:09 -0600
> > > Subject: Re: Read latency issue
> > >
> > > Interesting results. With PlayOrm, we did a 6 node test of reading 100
> rows from 1,000,000 using PlayOrm Scalable SQL. It only took 60ms. Maybe we
> have better hardware though??? We are using 7200 RPM drives so nothing
> fancy on the disk side of things. More nodes puts at a higher throughput
> though as reading from more disks will be faster. Anyways, you may want to
> play with more nodes and re-run. If you run a test with PlayOrm, I would
> love to know the results there as well.
> > >
> > > Later,
> > > Dean
> > >
> > > From: Arindam Barua <abarua@247-inc.com<mailto:abarua@247-inc.com>>
> > > Reply-To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>"
> <user@cassandra.apache.org<mailto:user@cassandra.apache.org>>
> > > Date: Monday, October 1, 2012 4:57 PM
> > > To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>" <
> user@cassandra.apache.org<mailto:user@cassandra.apache.org>>
> > > Subject: Read latency issue
> > >
> > > unning a query to like “select * from <table_name> where atag=<foo>”,
> where ‘atag’ is the first column of the composite key, from either JDBC or
> Hector (equivalent code), results in read times of 200-300ms from a remote
> host on the same network. The query returned around 800 results. Running
> the same query on a Cassandra host results in a read time of ~110-130 ms.
> > > Using read consistency of ONE reduces the read latency by ~20ms,
> compared to using QUORUM.
> > >
> > > Enabling row cache did not seem to change the performance much.
> Moreover, the row cache ‘size’ according to nodetool was very tiny. Here is
> a snapshot of the nodetool info after running few read tests:
> > > Key Cache : size 2448 (bytes), capacity 104857584 (bytes), 231 hits,
> 266 requests, 1.000 recent hit rate, 14400 save period in seconds
> > > Row Cache : size 96 (bytes), capacity 4194304000 (bytes), 9 hits, 13
> requests, NaN recent hit rate, 0 save period in seconds
> > >
>
>

Mime
View raw message