In my post on calculating throughput and response time I discussed how to measure the average throughput and response time for a given amount of time. I think it’s important to understand how to calculate these averages, but providing a single average causes you to mask other important trends and information about the system behavior.
This is a given in any statistical analysis. We don’t want to publish a large set of data because there is too much information, so we try to extract important information. But if we shrink …

In software, response time measures a client’s perspective of the total time that a system takes to process a request (including latency). The response time of a single request is not always representative of a system’s typical response time. In order to get a good measure of response time, one will usually calculate the average response time of many requests. Response time is usually measured in units of “seconds / request” or “seconds / transaction”. (Note: Don’t confuse response time and latency.)
Throughput is the measure of the number of messages …

Some people use the terms response time and latency interchangeably when talking about software performance. It is important to distinguish the difference.
Latency is the delay incurred in communicating a message (the time the message spends “on the wire”). The word latent means inactive or dormant, so the processing of a user action is latent while it is traveling across a network.
Changes in latency are typically unavoidable through changes to your code. Latency is a resource issue, which is affected by hardware adequacy and utilization.
Example: The latency in a phone …