> For the complete documentation index, see [llms.txt](https://wiki.loadium.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.loadium.com/features/test-report.md). # Test Report {% embed url="" %} A test report in Loadium provides a comprehensive view of your test execution, combining detailed performance metrics, visual graphs, and analytical insights to help you evaluate system behavior under load. When you open a test report in Loadium, you are presented with a set of dedicated tabs that help you analyze the test from different perspectives. **Overview, Request Stats, Timeline Graph, Responses, Errors, Scatter Plot, AI Analysis, Load Engines & Logs** work together to provide both high-level insights and detailed, step-by-step breakdowns of your test results. {% tabs %} {% tab title="Overview" %} The **Overview** tab provides a high-level summary of the test execution, highlighting key performance metrics such as response time, throughput, error rate, and user load to help you quickly assess overall system performance.

{% endtab %} {% tab title="Request Stats" %} **Request Stats** tab provides a detailed, endpoint-level breakdown of test performance, allowing you to analyze metrics such as response time, throughput, and error rate for each request individually, along with visual insights like response type distribution and performance trends.

{% endtab %} {% tab title="Timeline Graph" %} The Timeline Graph tab allows you to create custom visualizations by selecting specific endpoints and performance metrics, enabling you to track and compare how chosen metrics behave over time.

{% endtab %} {% tab title="Responses" %} The Responses tab provides a visual representation of response data collected throughout the test, showing the distribution of HTTP status codes and request labels through charts to help identify patterns and anomalies.

{% endtab %} {% tab title="Errors" %} The Errors tab provides a detailed view of all errors encountered during the test, showing their distribution over time and across response codes, with the ability to filter and analyze errors on a per-label basis.

{% endtab %} {% tab title="Scatter Plot" %} The Scatter Plot tab visualizes the response times of a selected endpoint as individual data points, allowing you to analyze the distribution and variability of responses in detail.

{% endtab %} {% tab title="AI Analysis" %} The AI Analysis tab provides an AI-generated performance summary by analyzing test data, identifying patterns and anomalies, and presenting actionable insights; this feature is currently in beta and may evolve over time.

{% endtab %} {% tab title="Load Engines & Logs" %} The Load Engines & Logs tab displays resource usage of the load generators during the test, including metrics such as CPU, memory, and network utilization, and also allows you to monitor engine logs in real time.

{% endtab %} {% endtabs %} ### 1. Analytics #### 1.1 Overview The **Overview** page provides a comprehensive summary of the test execution, allowing you to quickly evaluate overall system performance before moving into detailed analysis. It combines **key metrics, aggregated statistics, and visual graphs** to give a complete picture of how the system behaved under load. At the top of the page, you can find the test configuration: * **Start / End Time** → Defines the test window * **Duration** → Total runtime of the test * **Ramp Up** → Time to reach target load * **Engines & Users per Engine** → Defines total load generation * **Location** → Region where traffic originated * **Iteration** → Loop behavior of the test This section is critical to correctly interpret results, as performance is directly affected by these parameters. *** #### Key Metrics (KPI Cards) The KPI cards provide a quick performance snapshot: * **Max Users Reached**\ → Indicates whether the target load was successfully applied * **Avg Response Time**\ → General performance indicator (but should not be used alone) * **Avg Throughput (RPS)**\ → System processing capacity * **Error Rate**\ → Overall system reliability * **95th Percentile**\ → Real user experience indicator (more critical than average) {% hint style="warning" %} Focus on **percentiles and error rate**, not just averages. {% endhint %} *** #### Test Summary This section aggregates key statistics into four groups: {% tabs fullWidth="false" %} {% tab title="Response Time" %} * Average * 95th percentile * 99th percentile Shows **latency distribution and consistency.** {% endtab %} {% tab title="Throughput" %} * Average * Peak * Lowest Helps detect: * system limits * instability under load {% endtab %} {% tab title="Stats" %} * Total requests * Success / Failed counts Used to validate: * overall success ratio * reliability of the system {% endtab %} {% tab title="Data Transfer" %} * Total transferred data * Bandwidth * Request size Useful for: * network impact analysis * payload-related bottlenecks {% endtab %} {% endtabs %} #### Response Time Distribution

This graph shows how response-related metrics behave over time. Use this to: * detect spikes * identify unstable response patterns * correlate load vs performance #### Throughput Over Time

Helps you: * identify performance drops * detect saturation points * correlate errors with load #### Error Distribution

Critical for: * spotting instability * identifying when the system starts failing #### Response Time Scatter

Displays each request as a data point: Useful for: * detecting outliers * understanding response variability * identifying inconsistent performance {% hint style="info" %} #### How to Analyze Overview Start your analysis by answering: * Did the system reach the target user load? * Are response times stable? * Is error rate acceptable? * Does throughput remain consistent? 1. Start with **Overview** 2. If issues exist: * Go to **Request Stats** → find problematic endpoints * Check **Errors** → identify root cause * Use **Scatter Plot** → analyze variability {% endhint %} #### 1.2 Request Stats The **Request Stats** tab provides a detailed, endpoint-level breakdown of test performance, allowing you to analyze how each request behaves under load. It is the primary page used to identify **slow endpoints, high error rates, and performance bottlenecks**. At the top of the page, you can see aggregated metrics: * **Total Requests** → Total number of requests sent * **Avg. Response Time** → Overall average elapsed time * **Avg. Throughput (RPS)** → Requests per second * **Success / Failed** → Request outcome distribution These give a quick overview before diving into endpoint-level analysis. *** #### Performance Analysis by Label The main table displays performance metrics for each endpoint (label): * **Total Hits** → Number of requests sent * **Error Hits** → Failed requests * **Error Rate (%)** → Failure ratio * **Avg Throughput (RPS)** → Endpoint load handling * **Avg Response Time** → Average elapsed time * **Median / Percentiles** → Response consistency Use this table to: * identify slow endpoints * detect endpoints with high error rates * compare performance across requests *** #### Filtering & Interaction

You can filter the table using: * **All** → Shows all requests * **Success** → Only successful requests * **Errors** → Only failed requests This helps isolate problematic requests quickly. Using the timeline selector (top right), you can: * focus on a specific time window * analyze performance during spikes or failures

{% hint style="info" %} All filters (status + time range) are applied in real time. The table automatically updates to reflect: * selected request status * selected time interval This allows precise and targeted analysis. {% endhint %} *** #### Key Insights This section highlights automatically detected issues such as: * High error rates * Slow endpoints * Performance anomalies Helps you quickly identify critical problems without manual analysis. #### Response Type Distribution This chart shows how requests are distributed across response time ranges; fast responses (e.g. <200ms), slow responses, very slow responses. Useful for: * understanding overall system speed * identifying latency distribution *** {% hint style="info" %} #### How to Analyze This Page Start by: 1. Checking **error rate per endpoint** 2. Identifying **slowest endpoints (avg & P95)** 3. Filtering by **Errors** to isolate failures 4. Using **time filter** to zoom into problematic moments **Best Practice** * Do not rely only on **average response time** * Always check: * **P95 / P99** * **error rate** * **throughput consistency** {% endhint %} {% hint style="success" %} #### Typical Use Case * Go to **Request Stats** * Filter → **Errors** * Identify failing endpoint * Narrow down with **time filter** * Investigate further in **Errors / Logs** {% endhint %} #### 1.3 Timeline Graph The **Timeline Graph** tab allows users to create custom time-based charts by selecting endpoints, metric categories, and aggregation types. Users can first choose an endpoint from the **Endpoints** list, then select a metric category such as **Hits, Errors, Response Time, Percentile, Latency, Concurrent User,** or **Received Mbps**. After selecting the required aggregation type, the series can be added to the chart using **Add to Chart**.

A maximum of **5 active series** can be added to the chart. This allows users to compare multiple endpoints and metrics on the same timeline.

This page is useful for analyzing performance trends, comparing endpoint behavior, and identifying changes such as response time spikes, error increases, or throughput drops during the test. {% hint style="info" %} ### How to Analyze This Page To effectively analyze the Timeline Graph: * Start by selecting a **single endpoint and one metric** (e.g., Response Time) to understand baseline behavior * Gradually add more **endpoints or metrics** to compare performance * Observe how metrics change over time and look for: * **spikes** in response time * **sudden increases in errors** * **drops in throughput** * Use combinations such as: * Response Time + Errors → to detect failure impact * Throughput + Response Time → to identify saturation points * Concurrent Users + Response Time → to understand load impact The goal is to identify **patterns, correlations, and anomalies** rather than focusing on a single metric. {% endhint %} {% hint style="success" %} ### **Typical Use Case** A common workflow when using the Timeline Graph: 1. A performance issue is detected in the **Overview** page 2. Navigate to **Timeline Graph** 3. Select the affected **endpoint** 4. Add **Response Time** and **Errors** as metrics 5. Observe when the issue occurs during the test 6. Add additional endpoints or metrics to compare behavior This helps determine: * whether the issue is **endpoint-specific or system-wide** * if performance degradation is **load-related or intermittent** {% endhint %} #### 1.4 Responses The **Responses** tab provides a visual overview of all responses received during the test, allowing you to analyze how requests are distributed across HTTP status codes and endpoints. It is mainly used to understand **response behavior, success rates, and error distribution patterns**. At the top of the page, you can find: * **Total Responses** → Total number of responses received * **Success (2XX & 3XX)** → Successful request ratio * **Client Errors (4XX)** → Client-side issues * **Server Errors (5XX)** → Server-side failures This gives a quick understanding of **system health and reliability**. *** #### Response Code Distribution

This chart shows how responses are distributed across HTTP status codes: * 2XX → Successful responses * 4XX → Client errors * 5XX → Server errors Use this to: * quickly identify error-heavy scenarios * understand overall response quality #### Distribution by Label

This visualization shows how responses are distributed across endpoints: Helps you: * identify which endpoints receive most traffic * detect endpoints contributing to errors #### Responses by Label This section provides a detailed breakdown of responses grouped by endpoint (label). Users can apply filters based on: * **Status Codes** (e.g., 200, 404, 500) * **Labels (endpoints)**

The table dynamically updates based on selected filters. *** {% hint style="info" %} ## How to Analyze This Page * Start by checking the **success vs error ratio** * Look at the **Response Code Distribution** to detect dominant error types * Use **filters** to: * isolate specific status codes (e.g., only 5XX) * focus on a specific endpoint Focus on identifying: * unexpected error codes * endpoints with abnormal response behavior {% endhint %} {% hint style="success" %} ## Typical Use Case A common workflow: 1. High error rate is detected in **Overview** 2. Navigate to **Responses** 3. Check **Response Code Distribution** to identify error types 4. Filter by **status code (e.g., 500)** 5. Identify which endpoints are returning these errors This helps determine: * whether errors are **client-side or server-side** {% endhint %} #### 1.5 Errors The **Errors** tab provides detailed information about the errors encountered during the test, helping users understand when, where, and how failures occurred. This page is mainly used for **failure analysis and troubleshooting**. At the top of the page, users can see a quick summary of error behavior: * **Total Errors** → Total number of failed requests * **Avg Error Rate** → Average error percentage across the test * **Peak Error Rate** → Highest observed error rate * **Error Types** → Number of different error categories detected *** #### Error Rate Over Time This chart shows how the error rate changes during the test execution. It helps users identify: * when errors started * whether errors increased under load * whether failures happened continuously or only during specific periods #### Error Types Breakdown

The **Error Types Breakdown** chart groups errors by response code or error type, such as: * 4XX errors * 5XX errors * timeout errors * connection refused errors This helps users understand the main failure categories in the test. #### Errors by Label The **Errors by Label** section shows which endpoints produced errors during the test. Users can expand each label to view more detailed error information, including the **timestamp** of the error. This makes it easier to identify exactly when failures occurred for each service or request.

*** {% hint style="info" %} #### How to Analyze This Page Start by checking the total error count and peak error rate. Then review the **Error Rate Over Time** chart to see whether the issue happened during a specific period. After that, use **Error Types Breakdown** to understand the main error categories, and check **Errors by Label** to identify which endpoint or service caused the failures. {% endhint %} {% hint style="success" %} ### Typical Use Case A common workflow: 1. A high error rate is detected in **Overview** 2. Open the **Errors** tab 3. Check when the errors occurred in **Error Rate Over Time** 4. Identify the dominant error type in **Error Types Breakdown** 5. Use **Errors by Label** to find the affected endpoint 6. Expand the label to review timestamp-level error details This helps determine whether the issue is related to a specific endpoint, a specific time period, or a general system failure. {% endhint %} ### 2. Advanced #### 2.1 Scatter Plot The **Scatter Plot** tab visualizes individual requests for a selected endpoint as data points, allowing you to analyze response time distribution, variability, and performance consistency in detail. It is mainly used to detect **outliers, instability, and response time patterns**. At the top of the page: * **Total Requests** → Number of requests analyzed * **Avg Response Time** → Weighted average elapsed time * **Correlation Score** → Relationship between load and response time * **Total Outliers** → Requests outside normal range * **Total Errors** → Failed requests These provide a quick summary of distribution quality. *** #### Response Time Scatter

This chart displays: * Each request as a **single data point** * **Time on X-axis** * **Response time on Y-axis** * Color-coded: * Success * Error This allows you to see: * response time spread * clusters of slow/fast responses * anomalies and spikes {% hint style="info" %} By analyzing the scatter: * Tight clustering → **stable performance** * Wide spread → **inconsistent response times** * Isolated high points → **outliers** Helps understand how predictable your system is under load. {% endhint %} *** #### Label Correlation Analysis

This table provides statistical insights per endpoint: * **Avg Response Time** * **P95 / P99** * **Correlation Score** * **Outliers** * **Errors** Use this to: * compare endpoints * detect performance degradation patterns * identify problematic services #### Performance Insights

The page highlights: * **Performance Strengths** → stable and fast endpoints * **Areas for Attention** → slow or error-prone endpoints 👉 These summaries help prioritize optimization efforts. *** {% hint style="info" %} ### How to Analyze This Page * Select an endpoint and observe the scatter distribution * Look for: * **outliers (extreme points)** * **wide distribution (instability)** * **clusters shifting over time** * Check correlation: * high correlation → performance affected by load * low correlation → other bottlenecks (DB, network, etc.) 👉 Focus on consistency, not just average values. {% endhint %} {% hint style="success" %} ### Typical Use Case A common workflow: 1. A slow endpoint is identified in **Request Stats** 2. Open **Scatter Plot** 3. Select the endpoint 4. Analyze distribution: * Are responses consistent? * Are there spikes? 5. Check **P95 / P99 and outliers** 6. Use correlation to understand if issue is load-related This helps determine: * whether performance issues are **systematic or random** * if the endpoint is **stable or unpredictable** {% endhint %} ### 3. Tools #### 3.1 AI Analysis The **AI Performance Analysis** page provides an automated, AI-driven interpretation of your load test results, transforming raw performance data into **actionable insights, root cause analysis, and optimization recommendations**. {% hint style="warning" %} This feature is currently in beta and available as a premium capability. {% endhint %} The system analyzes your test data using multiple machine learning models, including: * **Anomaly Detection** → identifies abnormal behavior * **Pattern Recognition** → detects recurring trends * **Root Cause Analysis** → suggests possible reasons for issues * **Predictive Modeling** → estimates system behavior under load Instead of manually analyzing charts, users get a **ready-to-use performance report**. At the top of the page:

* **AI Performance Score** → overall system health score * **Anomalies Detected** → number and severity of issues * **Patterns Identified** → detected behavioral trends * **Confidence Level** → reliability of AI predictions These provide a quick executive-level summary. #### Executive Summary

This section delivers a **high-level interpretation** of the test: * overall system stability * performance limits * detected bottlenecks * critical events during the test Ideal for sharing results with stakeholders or management. #### Strengths, Issues & Opportunities The AI groups findings into:

		Cover image
Strenghts	stable baseline performance consistent response times predictable scaling behavior	Screenshot at Apr 28 09-09-33.png
Critical Issues	performance spikes resource saturation (CPU, memory, DB, etc.) error rate increases	Screenshot at Apr 28 09-10-47.png
Opportunities	optimization suggestions scaling improvements architecture enhancements	Screenshot at Apr 28 09-11-39.png

#### Performance Timeline

Breaks down the test into phases: * steady state * degradation periods * recovery phases Helps understand when issues occurred, not just what happened. #### Anomaly Detection Timeline

The system automatically detects and lists anomalies such as: * response time spikes * sudden error increases * throughput drops Each anomaly includes: * severity level * affected requests * confidence score * detailed drill-down links

This enables fast troubleshooting. #### Identified Performance Patterns AI detects recurring behaviors like: * steady state performance * performance spikes * recovery patterns * gradual degradation * load-based slowdowns Useful for understanding long-term system behavior. #### AI-Powered Recommendations

Provides prioritized improvement suggestions: * database optimization * connection pool scaling * caching strategies * auto-scaling configuration * resilience patterns (e.g., circuit breaker) Each recommendation includes: * expected impact * implementation effort * technical guidance Helps teams move from analysis → action quickly *** {% hint style="info" %} ### How to Analyze This Page * Start with **AI Score and Summary** * Review **critical issues first** * Check anomalies and their timestamps * Analyze detected patterns * Focus on high-impact recommendations Treat this page as a **decision-making tool**, not just a report. {% endhint %} {% hint style="success" %} ### Typical Use Case A common workflow: 1. Run a load test 2. Open AI Analysis 3. Review Executive Summary 4. Identify critical anomalies 5. Check root cause suggestions 6. Apply recommended optimizations This reduces analysis time significantly and helps teams act faster. {% endhint %} #### 3.2 Load Engines & Logs The **Load Engines & Logs** page provides visibility into the infrastructure running your load test, including resource usage and engine-level logs. **What You Can See** * Active load generators (engines) * CPU and memory usage * Network traffic (send/receive) * Region and provider details (AWS, Azure, GCP, Oracle)

Helps you understand how the test environment behaves during execution. #### Logs & Monitoring Users can also: * Track engine logs in real-time * Monitor test execution behavior at infrastructure level * Identify issues related to load generators (not just the system under test) {% hint style="info" %} ### How to Analyze This Page * Check if engines are **overloaded (CPU / Memory spikes)** * Verify network usage consistency * Review logs for unexpected errors during test execution Useful for distinguishing **test-side issues vs system-side issues** {% endhint %} {% hint style="success" %} ### Typical Use Case * Test results look unstable → check engine resource usage * Unexpected failures → inspect engine logs * Multi-region tests → compare generator performance across regions {% endhint %}

Strenghts

Critical Issues

Opportunities