Metriche chiave delle prestazioni

Performance testing isn't just about "making things faster." It's about understanding how your system behaves under load.

Performance metrics are key measurements that help us quantify this behavior. They tell us if our system is meeting user expectations and business goals.

Response Time is the total time it takes for a system to respond to a user request. Think of it as how long you wait after clicking a button until the page loads.

• Average Response Time: The typical time users wait.
• Percentiles (e.g., 90th, 95th): These show the response time for a certain percentage of requests. For example, 95th percentile means 95% of requests were faster than this time. They're great for finding outliers!

Throughput measures the amount of work a system can handle over a specific period. It tells you how many requests or transactions your system can process.

• Common units are Requests Per Second (RPS) or Transactions Per Second (TPS).
• A high throughput generally means the system is efficient and can serve many users simultaneously.

The Error Rate is the percentage of failed requests compared to the total number of requests during a test. A failed request might be a server error (like HTTP 500) or a timeout.

• Ideally, your error rate should be 0% during a performance test.
• A high error rate indicates instability or capacity issues under load.

While often used interchangeably, Latency is slightly different from Response Time.

• Latency is the time it takes for a single data packet to travel from source to destination. It's often related to network delay.
• Response Time includes latency but also adds the time the server spends processing the request and sending the response.

Resource Utilization metrics track how much of your system's hardware resources are being used during a test. These include:

• CPU Usage: How busy your processor is.
• Memory Usage: How much RAM is being consumed.
• Disk I/O: How often the system reads from or writes to storage.
• Network I/O: The amount of data flowing in and out of the system.

High utilization can indicate a bottleneck.

Concurrency refers to the number of active users or requests being processed at any given moment. In performance testing, we simulate this with Virtual Users (VUs).

• VUs mimic real users interacting with your application.
• Tracking VUs helps correlate other metrics (like response time or throughput) to the load applied.

Understanding metrics is one thing; knowing what values are "good" is another. This is where Baselines and Targets come in.

• A Baseline is the performance of your system under normal conditions, or from a previous test run.
• A Target is the specific performance goal you aim to achieve, often based on business requirements or Service Level Agreements (SLAs).

No single metric tells the whole story. You need to analyze them together to get a complete picture of your system's performance.

For example, high throughput with high error rates isn't good. Or fast response times with maxed-out CPU might mean you're at your limit.

Learning to interpret these relationships is key to effective performance testing.

Let's test your understanding of key performance metrics.

In this lesson, we explored crucial performance metrics:

• Response Time: How long it takes for a system to respond.
• Throughput: The volume of requests/transactions processed.
• Error Rate: The percentage of failed requests.
• Latency: Network delay.
• Resource Utilization: CPU, Memory, Disk, Network usage.
• Concurrency: Number of active users.

Understanding these metrics is fundamental to assessing and improving system performance.