4 ms·

Throughput improvement is nice but not game-changing. What I would be more interested in here is a comparison of the longest latency. One problem my former empl

Throughput improvement is nice but not game-changing. What I would be more interested in here is a comparison of the longest latency. One problem my former employer had in a large Cassandra deployment was GC pause times causing latency spikes exceeding SLAs for a critical service. They did eventually tune the cluster to avoid these issues but to be honest it kind of shook my faith in any JVM-based database (maybe unfairly).

rkarthik007 9y ago
Hi @jeremyjh - you are absolutely correct about p99 being more important than avg latency for critical services. We have done the following p99 measurements: - a p99 comparison of YugaByte vs Cassandra using YCSB - ran ndbench for a week and looked at the p99 of YB The results are looking really good for YugaByte in both cases. We are going to post that very soon to our forum, will x-post here as well.
- rpang 9y ago
  Our ndbench results for YugaByte DB were just posted on our forum https://forum.yugabyte.com/t/ndbench-results-for-yugabyte-db https://forum.yugabyte.com/t/ndbench-results-for-yugabyte-db. In gist, we ran ndbench for 7 days and our p99 was under 6 ms with no "long tail". It is achieved by cautious architectural design and implementation choices. More details are available in our post.
  - rpang 9y ago
    For those who are interested, our ndbench results post has just been moved to a new location: https://forum.yugabyte.com/t/yugabyte-db-p99-latencies-with-netflix-data-store-benchmark https://forum.yugabyte.com/t/yugabyte-db-p99-latencies-with-...
    - rpang 9y ago
      Some new updates on YCSB and p99 latencies. https://forum.yugabyte.com/t/ycsb-benchmark-results-for-yugabyte-and-apache-cassandra-again-with-p99-latencies/99 https://forum.yugabyte.com/t/ycsb-benchmark-results-for-yuga.... In our new benchmark run, we set up Apache Cassandra using G1 GC and a smaller heap size as suggested. Still, we observed a multitude of differences in throughput and p99 latencies in YugaByte over Apache Cassandra.
riffraff 9y ago
If they could tune the GC to enforce predictable pauses (which is common practice enough afaik), why would that shake your faith? The JVM cannot know in advance if you prefer throughput or predictability.
- jeremyjh 9y ago
  They managed to tune it to an acceptable level in our use case but we’d still see 50ms variation in the long tail responses. I think there are applications for whom that wouldn’t be acceptable. Like I said - it may not be fair but the impression I walked away with is that I don’t want GC in my database.
  - pkolaczk 9y ago
    GC development is not standing still. Oracle claims sub 10ms pause times and terabyte heaps their new ZGC. And there are good pauseless or almost pauseless alternatives from other vendors as well. https://www.google.pl/amp/s/www.infoworld.com/article/3235391/java/zgc-large-heap-java-garbage-collector-may-go-open-source.amp.html https://www.google.pl/amp/s/www.infoworld.com/article/323539...
  - riffraff 9y ago
    thanks for the clarification, I understand better now.

rkarthik007 9y ago

Hi @jeremyjh - you are absolutely correct about p99 being more important than avg latency for critical services. We have done the following p99 measurements: - a p99 comparison of YugaByte vs Cassandra using YCSB - ran ndbench for a week and looked at the p99 of YB The results are looking really good for YugaByte in both cases. We are going to post that very soon to our forum, will x-post here as well.

rpang 9y ago
Our ndbench results for YugaByte DB were just posted on our forum https://forum.yugabyte.com/t/ndbench-results-for-yugabyte-db https://forum.yugabyte.com/t/ndbench-results-for-yugabyte-db. In gist, we ran ndbench for 7 days and our p99 was under 6 ms with no "long tail". It is achieved by cautious architectural design and implementation choices. More details are available in our post.
- rpang 9y ago
  For those who are interested, our ndbench results post has just been moved to a new location: https://forum.yugabyte.com/t/yugabyte-db-p99-latencies-with-netflix-data-store-benchmark https://forum.yugabyte.com/t/yugabyte-db-p99-latencies-with-...
  - rpang 9y ago
    Some new updates on YCSB and p99 latencies. https://forum.yugabyte.com/t/ycsb-benchmark-results-for-yugabyte-and-apache-cassandra-again-with-p99-latencies/99 https://forum.yugabyte.com/t/ycsb-benchmark-results-for-yuga.... In our new benchmark run, we set up Apache Cassandra using G1 GC and a smaller heap size as suggested. Still, we observed a multitude of differences in throughput and p99 latencies in YugaByte over Apache Cassandra.

riffraff 9y ago

If they could tune the GC to enforce predictable pauses (which is common practice enough afaik), why would that shake your faith? The JVM cannot know in advance if you prefer throughput or predictability.

jeremyjh 9y ago
They managed to tune it to an acceptable level in our use case but we’d still see 50ms variation in the long tail responses. I think there are applications for whom that wouldn’t be acceptable. Like I said - it may not be fair but the impression I walked away with is that I don’t want GC in my database.
- pkolaczk 9y ago
  GC development is not standing still. Oracle claims sub 10ms pause times and terabyte heaps their new ZGC. And there are good pauseless or almost pauseless alternatives from other vendors as well. https://www.google.pl/amp/s/www.infoworld.com/article/3235391/java/zgc-large-heap-java-garbage-collector-may-go-open-source.amp.html https://www.google.pl/amp/s/www.infoworld.com/article/323539...
- riffraff 9y ago
  thanks for the clarification, I understand better now.