@cassandra.apache.orgmailto:user@cassandra.apache.org
Date: Monday, February 25, 2013 8:31 PM
To: user@cassandra.apache.orgmailto:user@cassandra.apache.org
user@cassandra.apache.orgmailto:user@cassandra.apache.org
Subject: Read Perf
Hi - I am doing a performance run using modified YCSB client and was able
be the same. The
only thing which changes is the columns and they keep getting added.
-Original Message-
From: Hiller, Dean [mailto:dean.hil...@nrel.gov]
Sent: 26 February 2013 09:21
To: user@cassandra.apache.org
Subject: Re: Read Perf
To find stuff on disk, there is a bloomfilter for each file
[mailto:dean.hil...@nrel.gov]
Sent: 26 February 2013 09:32
To: user@cassandra.apache.org
Subject: Re: Read Perf
In that case, make sure you don't plan on going into the millions or test
the limit as I pretty sure it can't go above 10 million. (from previous
posts on this list).
Dean
On 2/26/13 8
Hi - I am doing a performance run using modified YCSB client and was able to
populate 8TB on a node and then ran some read workloads. I am seeing an average
TPS of 930 ops/sec for random reads. There is no key cache/row cache. Question -
Will the read TPS degrade if the data size increases to
All,
I've done a bit more homework, and I continue to see long 200ms to 300ms
read times for some keys.
Test Setup
EC2 M1Large sending requests to a 5 node C* cluster also in EC2, also all
M1Large. RF=3. ReadConsistency = ONE. I'm using pycassa from python for all
communication.
Data Model
, is your problem. Perhaps consider RAID0 with ephemeral drives.
Dan
From: Ian Danforth [mailto:idanfo...@numenta.com]
Sent: November-03-11 18:34
To: user@cassandra.apache.org
Subject: Read perf investigation
All,
I've done a bit more homework, and I continue to see long 200ms to 300ms
