# YCSB Benchmark Results for YugaByte and Apache Cassandra (again) with P99 Latencies

**URL:** <https://forum.yugabyte.com/t/ycsb-benchmark-results-for-yugabyte-and-apache-cassandra-again-with-p99-latencies/99>\
**Category:** General\
**Created:** [November 23, 2017, 6:29pm UTC](https://forum.yugabyte.com/t/ycsb-benchmark-results-for-yugabyte-and-apache-cassandra-again-with-p99-latencies/99 "2017-11-23T18:29:45Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![rpang](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/rpang/32/20_2.png) [@rpang](https://forum.yugabyte.com/u/rpang)\
**Post date:** [November 23, 2017, 6:29pm UTC](https://forum.yugabyte.com/t/ycsb-benchmark-results-for-yugabyte-and-apache-cassandra-again-with-p99-latencies/99/1 "2017-11-23T18:29:45Z")

</div>

Since we shared our [YCSB Benchmark Results for YugaByte and Apache Cassandra](https://forum.yugabyte.com/t/ycsb-benchmark-results-for-yugabyte-and-apache-cassandra), we received great interest and feedback. The suggestions we received are:

- share 99th percentile (P99) latencies.
- run Apache Cassandra with Java G1 garbage collector and a smaller heap size.

We just did that and want to share the new results.

# Setup

- 3-node cluster in Google Compute (GCP)
- Each node is a n1-standard-16
  - 16 vcpu’s, Intel® Xeon® CPU @ 2.20GHz CPUs
  - 60GB RAM
  - 2 x 375 GB direct attached SSD

- Replication Factor = 3
- YugaByte: default configuration parameters were used.
- Apache Cassandra: 3.11.1 release. Non-default configuration parameters:
  - Garbage collector = G1GC
  - MAX\_HEAP\_SIZE = 12GB

- For writes:
  - YugaByte uses Raft (a distributed consensus) protocol for strong consistency.
  - With Apache Cassandra, quorum write setting was used.

- For reads:
  - YugaByte reads default to strongly consistent reads.
  - With Apache Cassandra, quorum read setting was used.

- YCSB client software was built from a fork of the open source repository. This time we further improved the use of “prepared” statements in the Cassandra binding (Git commit [5a42b2cec46cefc2cce61b938a92073af154c1e7](https://github.com/robertpang/YCSB/commit/5a42b2cec46cefc2cce61b938a92073af154c1e7)).
- YCSB maxexecution for each workload was set to 1 hour.

# Results

The benchmark was done for each system with 1 million, 5 million and 10 million keys. Again, we observed that YugaByte’s throughput outperformed Apache Cassandra’s by increasing margins as the number of keys (data density) increased.

![ycsb-throughput-chart](https://canada1.discourse-cdn.com/flex027/uploads/yugabyte/original/1X/b2880e16fb48287760feb9286bf872e08120ce31.png)

 ![ycsb-throughput-table](https://canada1.discourse-cdn.com/flex027/uploads/yugabyte/original/1X/31e62a9477f8b6a5c78e5704ac83ca5586ce3c3e.png)

In addition, we saw that YugaByte’s P99 latencies were markedly lower than Apache Cassandra’s, despite compactions running in the background. As noted in our earlier post on [YugaByte DB P99 latencies with Netflix Data Store Benchmark](https://forum.yugabyte.com/t/yugabyte-db-p99-latencies-with-netflix-data-store-benchmark), YB’s lower latencies are primarily due to better architecture for strong consistency (no quorum reads, no anti-entropy/read-repairs) and implementation in C++ (no Java garbage collection pauses).

 ![ycsb-p99-table](https://canada1.discourse-cdn.com/flex027/uploads/yugabyte/original/1X/495723a5bbb52692b9f6cba6d66f59207c0295dd.png)

---

<div class="post-metadata">

**Author:** ![dorian\_yugabyte](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/dorian_yugabyte/32/206_2.png) [@dorian\_yugabyte](https://forum.yugabyte.com/u/dorian_yugabyte)\
**Post date:** [March 8, 2023, 9:16am UTC](https://forum.yugabyte.com/t/ycsb-benchmark-results-for-yugabyte-and-apache-cassandra-again-with-p99-latencies/99/2 "2023-03-08T09:16:49Z")

</div>