Low throughput while benchmarking DynamoDB using YCSB

[rohannarde]

Hello,

I created a DyanamoDB table as instructed using a hash for "firstname" and assigned a read throughput of 1000 and a write throughput of 750. In the dynamodb.properties file in YCSB/dynamodb/conf I defaulted most of the settings including consistentReads as false.

I ran dynamoDB with varying recordcounts of 1000, 10000 and 50,000 and was surprised when I could achieve throughputs of 15-50 ops/sec on most of the workloads. I followed the workload sequence specified in "CoreWorkloads" page.

https://github.com/brianfrankcooper/YCSB/wiki/Core-Workloads

I ran the following command to load,

bin/ycsb load dynamodb -P dynamodb/conf/dynamodb.properties -p recordcount=1000 -p debug=true -P workloads/workloada -s > workloada_load.txt

To run the workload,

bin/ycsb run dynamodb -P dynamodb/conf/dynamodb.properties -p operationcount=1000 -p debug=true -P workloads/workloada -t -s > workloada_run.txt

Could there be something that I missed while configuring? Should I change the number of threads from the default value of 1?

Any help would be welcome.

--Rohan

[arnaudsjs]

I suffered the same problem while benchmarking several NoSQL databases using YCSB. After a bit of research it turned out that the recordcount property and the operationcount property have to be proportional to each other in order not to get a low throughput.

For example:

When I used the follow combination:

recordcount=1,000
operationcount=1,000,000,000

Throughput dropped a lot. While the combination:

recordcount=10,000
operationcount=10,000,000

seems to work very well.

What exactly causes this problem is not clear to me at the moment. But it's definitely a bug.

[rohannarde]

Hmm, that's a good workaround. Ill try and see what happens for me.

--Rohan

On Tue, May 20, 2014 at 12:21 AM, arnaud123 notifications@github.comwrote:

I suffered the same problem while benchmarking several NoSQL databases
using YCSB. After a bit of research it turned out that the recordcount
property and the operationcount property have to be proportional to each
other in order not to get a low throughput.

For example:

When I used the follow combination:

recordcount=1,000
operationcount=1,000,000,000

Throughput dropped a lot. While the combination:

recordcount=10,000
operationcount=10,000,000

seems to work very well.

What exactly causes this problem is not clear to me at the moment. But
it's definitely a bug.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/151#issuecomment-43593741
.

[busbey]

closing as stale. If you are still working on this issue, please reopen.

(the record count / operation count observation above sounds like contention in the datastore over access to the smaller number of records)