What is the difference between response time and throughput

Latency, Throughput, Bandwidth and Response Time; somehow these terms are very confusing. A new performance tester faces difficulty to understand these terms without example. Look at the above figure Figure The illustration shows a water tank Orange , water pipe Green , water Blue. The water tank represents a server, pipe represents communication channel with certain width and water represents data. You will get an idea about all four important terms i.

Latency, Bandwidth, Throughput and Response Time with this diagram. The time taken by water to travel from one end to another end is called Latency. In performance testing, the term latency or better to called Network Latency of a request is travel time from client to server and server to the client. Bandwidth shows the capacity of the pipe communication channel. Throughput requests per min, red grows until CPU is saturated and then remains constant - the CPU is operating at max throughput.

Once CPU is maxed out then response time must increase with load. In our case it increases predictably linearly with load. A thread-per-request system would drop off as load increases since the CPU has to spend more and more time context switching threads and not doing real work. Throughput is the measure of the number of messages that a system can process in a given amount of time. Through put- indicates the number of transactions per second an application can handle, the amount of transactions produced over time during a test.

Response time- Response time is the amount of time from the moment that a user sends a request until the time that the application indicates that the request has completed. Bigger hardware is not always faster—but it can usually handle more load. Bigger hardware is more like a wider highway than a faster car: you cannot drive faster—well, you are not allowed to—just because there are more lanes.

That is the reason that more hardware does not automatically improve slow SQL queries. We are not in the s anymore. The computing power of single core CPUs was increasing rapidly at that time. Most response time issues disappeared on newer hardware—just because of the improved CPU. It was like new car models consistently going twice as fast as old models—every year! However, single core CPU power hit the wall during the first few years of the 21st century.

There was almost no improvement on this axis anymore. To continue building ever more powerful CPUs, the vendors had to move to a multi-core strategy.

Even though it allows multiple tasks to run concurrently, it does not improve performance if there is only one task. Performance has more than just one dimension. Scaling horizontally adding more servers has similar limitations. Although more servers can process more requests, they do not improve the response time for one particular query. Proper indexing is the best way to reduce query response time—in relational SQL databases as well as in non-relational systems.

Proper indexing aims to fully exploit the logarithmic scalability of the B-tree index. Unfortunately indexing is usually done in a very sloppy way. Figure 3.

It is hardly possible to compensate for this effect by adding more hardware. These metrics are quite separate.

For example, when evaluating storage devices we are concerned with the average response time as the total device throughput. These goals of response time vs. Fast response time is often associated with index access. Response time is measured as average elapsed seconds.

High throughput is often associated with parallelized large-table full-table scans. Throughput is measured as transactions per second. Here are some common Oracle metrics for response time and throughput:.