There were some perf regressions from 8099 (storage engine rewrite) that were addressed around 3.10
https://issues.apache.org/jira/browse/CASSANDRA-12269 https://issues.apache.org/jira/browse/CASSANDRA-9766 To pick up those fixes, you'd want to benchmark 3.11.1 instead of 3.0.15 On Tue, Oct 17, 2017 at 8:04 PM, Yuji Ito <y...@imagine-orb.com> wrote: > Hi all, > > I'm comparing performance between Cassandra 2.2.10 and 3.0.15. > SELECT of 3.0.15 is faster than 2.2.10. > However, conditional INSERT and UPDATE of 3.0.15 are slower than 2.2.10. > Is it expected? If so, I want know why. > > I'm trying to measure performance for non-conditional operation next. > > Environment: > - 3 nodes in a single cluster > - AWS EC2 i3.large (2 cores, 30GB memory, NVMe SSD) > - Cassandra commitlog and data are stored in NVMe SSD > > Configuration: > - Replication factor: 3 > - commitlog_sync: batch > - conccurent_reads: 512 > - concurrent_writes: 512 > > Request: > - SELECT "id", "val" from testdb.testtbl WHERE "id" = id with CL.SERIAL > - INSERT INTO testdb.testtbl ("id", "val") VALUES (id, val) IF NOT EXIST > - UPDATE testdb.testtbl SET "val" = val WHERE "id" = id IF EXISTS > - Client program requests these operations via Java driver > > Result: > > - INSERT throughput [operations per sec] > > | Concurrency | 2.2.10 [op/s] |3.0.15 [op/s] | > | 1 | 303 | 263 | > | 2 | 526 | 454 | > | 4 | 784 | 666 | > | 8 | 1066 | 888 | > | 16 | 1391 | 1194 | > | 32 | 1649 | 1428 | > | 64 |1802 | 1553 | > > - UPDATE throughput > > | Concurrency | 2.2.10 [op/s] | 3.0.15 [op/s] | > | 1 | 322 | 277 | > | 2 | 606 | 512 | > | 4 | 1000 | 727 | > | 8 | 1250 | 1012 | > | 16| 1495|1280 | > | 32| 2147|1739 | > | 64| 3248|2949 | > > - SELECT throughput > > | Concurrency | 2.2.10 [op/s] | 3.0.15 [op/s] | > | 1 | 454 | 476 | > | 2 | 869 | 909 | > | 4 | 1333 | 1333 | > | 8 | 1818 | 1777 | > | 16 | 2424 | 2539 | > | 32 | 2990 | 3018 | > | 64 | 3422 | 3699 | > > Thanks, > Yuji >
