# What is throughput in load testing?

> Throughput is the rate of work a system completes under load, measured in requests, pages, or bytes per second. Here's how to read it in load test results.

Source: https://loadster.com/faqs/throughput-in-load-testing/

Throughput is the amount of work your system completes during a period of time, typically measured in requests per
second, pages per second, bytes per second, or even key transactions per second.

Response time tells you how long each individual interaction takes, while throughput tells you how much total work the
system completes under load.

## How Throughput Is Measured

Throughput can be measured in several ways. Which way is most useful depends on what you're testing. Requests or pages
per second are common measurements for websites and APIs. Transactions per second might be more useful when your
requirements are expressed as business operations (like orders or messages). Bytes per second is important when network
bandwidth could be a bottleneck, such as with large downloads, media, or file uploads.

Loadster reports several measurements of throughput during and after every test. The *Network Throughput* graph shows
the number of bytes and bits transferred per second, and the *Transaction Throughput* graph shows pages and hits per
second.

If you're not sure whether your target should be a request rate, a transaction rate, or a user count, check out the FAQ
on [RPS vs TPS vs concurrent users](https://loadster.com/faqs/rps-tps-concurrent-users/).

## Reading Throughput Curves in a Load Test

The shape of the throughput curve as you ramp up the load can tell you a lot about your system's capacity. As long as
the system has enough capacity, throughput should generally increase along with the load. For example, doubling the
number of bots might produce approximately twice as many requests per second while response times remain steady, as long
as no bottlenecks are reached.

Once a resource becomes saturated, throughput might level off even though the bot count continues to rise. At the same
time, response times usually start increasing because requests are waiting longer to be processed. In other
words, requests are arriving faster than they can be processed, so they get jammed up.

Let's say throughput rises steadily to 900 requests per second with 400 bots, but stays around 900 requests per second
as you ramp to 600 bots while the p90 response time triples. This is a very strong sign that you've reached the system's
current capacity ceiling. The additional demand isn't producing more completed work; instead, it's creating longer
queues for the same rate of completed work.

It's helpful to look at throughput alongside the response time and error graphs in the same report to identify this
pattern. See [Analyzing Test Results](https://loadster.com/manual/analyzing-test-results/) for more about interpreting your test results.

## Common Throughput Surprises

Byte throughput sometimes comes out higher than your initial estimate because of page resources, headers, and repeated
transfers that weren't included in the calculation. The FAQ
on [why your load test's throughput might be higher than expected](https://loadster.com/faqs/load-test-throughput-bytes-higher-than-expected/)
covers the most common reasons.

Compression and caching can have the opposite effect. Gzip can reduce transfer sizes considerably, and cached responses
might not reach the origin server at all. If you're testing through a CDN, the origin throughput might stay low even
under heavy traffic because the CDN handles most of the requests.

Make sure you know which layer of the system you're measuring when you interpret results.