# YugaByte DB P99 latencies with Netflix Data Store Benchmark

**URL:** <https://forum.yugabyte.com/t/yugabyte-db-p99-latencies-with-netflix-data-store-benchmark/94>\
**Category:** General\
**Created:** [November 13, 2017, 7:00pm UTC](https://forum.yugabyte.com/t/yugabyte-db-p99-latencies-with-netflix-data-store-benchmark/94 "2017-11-13T19:00:09Z")\
**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 13, 2017, 7:00pm UTC](https://forum.yugabyte.com/t/yugabyte-db-p99-latencies-with-netflix-data-store-benchmark/94/1 "2017-11-13T19:00:09Z")

</div>

Recently we shared [YCSB benchmark results for YugaByte DB](https://forum.yugabyte.com/t/ycsb-benchmark-results-for-yugabyte-and-apache-cassandra). Apart from YCSB, [Netflix Data Store Benchmark (NDBench)](https://github.com/Netflix/ndbench) is another publicly available, cloud-enabled benchmark tool for data store systems. We ran NDBench against YugaByte DB for 7 days and want to share our results:

## Setup

YugaByte DB machines:

- 6-node cluster in Amazon Web Service (AWS). Each node is a i3.2xlarge machine with:
  - 8 vCPUs Intel® Xeon® CPU E5-2686 v4 (Broadwell) @2.3 GHz
  - 61GB RAM
  - 1.9TB direct attached SSD
  - Same availability zone

- Replication factor = 3
- Default YugaByte DB configuration parameters were used.

NDBench machine:

- 1 c3.xlarge machine
  - 4 vCPUs Intel® Xeon® CPU E5-2680 v4 (Ivy Bridge)
  - 7.5GB RAM

- Same availability zone as YugaByte DB cluster.

NDBench configuration used:

```auto
# Data size
ndbench.config.numKeys=20000000 # Backfill keys
ndbench.config.numValues=1000
ndbench.config.dataSize=1024
ndbench.config.cass.colsPerRow=8
# Number of worker threads
ndbench.config.numReaders=8
ndbench.config.numWriters=8
# Consistency level
ndbench.config.cass.writeConsistencyLevel=LOCAL_QUORUM
ndbench.config.cass.readConsistencyLevel=LOCAL_QUORUM
# Request per second (RPS)
ndbench.config.readRateLimit=7200
ndbench.config.writeRateLimit=1800

```

## Results

 ![ndbench](https://canada1.discourse-cdn.com/flex027/uploads/yugabyte/original/1X/af3b9cfaf7543222f1bdf806d92f7dd521d76aba.png)

- Execution time: 7 days (163 hours)
- Total successful reads = 4.11 billion, writes = 1.05 billion
- Latencies (milliseconds) observed:
  - Read: Avg = 1.368ms, P95 = 3.311ms, P99 = 5.722ms, P995 = 6.866ms
  - Write: Avg = 1.803ms, P95 = 2.299ms, P99 = 3.311ms, P995 = 4.768ms

Throughout the entire run, compactions were enabled and running in the background. In spite of that, our P99 (99% percentile) read/write latencies were still under 6 ms. These contrast significantly to much higher P99s seen with Apache Cassandra - primarily due to architectural reasons (eventual consistency needs background anti-entropy/read-repairs; quorum reads to achieve higher consistency put multiple servers in the critical path of each request) as well as implementation choices (Java implementation, GC pauses, etc.).

---

<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:15am UTC](https://forum.yugabyte.com/t/yugabyte-db-p99-latencies-with-netflix-data-store-benchmark/94/2 "2023-03-08T09:15:30Z")

</div>