liveBook · Manning

Throughput

As explained in ScyllaDB in Action

Throughput is the rate at which a system completes operations or processes data over time.

Throughput measures how much work a system completes over time. In ScyllaDB testing, it appears as operations, partitions, or rows processed per second. section 11.2.2

Use throughput to interpret database performance:

  • Increase test traffic gradually and watch whether throughput continues to grow. section 11.2.2
  • Read throughput can rise while latency worsens, so evaluate both measurements together. section 11.2.2
  • During migration, raise source or destination throughput only until either database begins degrading. section 12.2

A load-test comparison

One test reaches 5,476 operations per second with 4.5-millisecond 99.9th-percentile latency. A heavier run reaches 24,619 operations per second, but latency rises to 44.9 milliseconds at the same percentile.

How ScyllaDB in Action covers it

How deep it goes
Compares operations-per-second results with latency during progressively heavier tests, without developing a formal capacity model.
Examples
Uses cassandra-stress results, partition and row rates, Grafana dashboards, and a source-to-destination migration scenario.
What you can do after
Diagnose database capacity with cassandra-stress and Grafana while balancing throughput against latency and degradation.
How it connects
Connects throughput with latency, load testing, database migration, reads, and writes.

Also explained in

Compare how 20 books explain throughput →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of ScyllaDB in Action. The section links point to the parts of the book it draws on.