Timing Metrics in LPS

LPS provides comprehensive timing metrics to help you understand where time is spent during HTTP requests. These metrics can be used in failure rules, termination rules, and are displayed in the dashboard.

Client-Side Timing Metrics

These metrics are measured by the LPS client and are always available:

Metric	Aliases	Description
`TotalTime`	-	Total request duration from start to finish
`TTFB`	`TimeToFirstByte`	Time from request sent until first byte received
`WaitingTime`	`Waiting`	Server processing time (TTFB - TCP - TLS)
`TCPHandshake`	`TCP`	TCP connection establishment time
`TLSHandshake`	`TLS`, `SSL`, `SSLHandshake`	TLS/SSL handshake negotiation time
`SendingTime`	`Sending`, `Upload`, `Upstream`	Time to upload the request body
`ReceivingTime`	`Receiving`, `Download`, `Downstream`	Time to download the response body

Aggregations

All timing metrics support the following statistical aggregations:

.P50 - 50th percentile (median)
.P90 - 90th percentile
.P95 - 95th percentile
.P99 - 99th percentile
.Avg or .Average - Mean value
.Min - Minimum value
.Max - Maximum value

Example usage:

failureRules:
  - metric: "TotalTime.P90 > 500"
  - metric: "TTFB.P95 > 200"
  - metric: "TCPHandshake.Avg > 50"

Server-Side Timing Metrics

LPS can parse the Server-Timing HTTP response header to extract server-side performance data. This gives you visibility into what's happening inside your server.

Metric	Aliases	Description
`ServerTime`	`Server`	Total server processing time
`ServerTimeDB`	`DB`, `Database`	Database query time
`ServerTimeCache`	`Cache`	Cache operation time
`ServerTimeApp`	`App`, `Application`	Application logic processing time

Enabling Server-Timing Parsing

To enable server timing metrics, configure the HTTP client:

lps httpclient --servertimeheader "<header-name>" --servertimeformat <format>

Supported Header Formats

LPS supports three formats for parsing server time headers:

Format	Description	Example Header Value
`ServerTiming`	W3C Server-Timing format with named metrics	`db;dur=53, cache;dur=5, app;dur=120`
`Milliseconds`	Simple numeric value in milliseconds	`178` or `178ms`
`Seconds`	Simple numeric value in seconds	`0.178` or `0.178s`
`Auto`	Auto-detect format (recommended)	Any of the above

Format Details

1. ServerTiming (W3C Standard)

The standard W3C Server-Timing format with named metrics and breakdown support:

Server-Timing: db;dur=53, cache;dur=5, app;dur=120, total;dur=178

Each metric has:

A name (e.g., db, cache, app)
A duration in milliseconds (dur=VALUE)

This format provides the richest data with breakdown into ServerTimeDB, ServerTimeCache, and ServerTimeApp.

2. Milliseconds

A simple numeric value representing total server time in milliseconds:

X-Response-Time: 178
X-Response-Time: 178ms

Only populates ServerTime (total). No breakdown available.

3. Seconds

A simple numeric value representing total server time in seconds:

X-Response-Time: 0.178
X-Response-Time: 0.178s

LPS automatically converts to milliseconds. Only populates ServerTime (total). No breakdown available.

4. Auto (Recommended)

Automatically detects the format based on the header value:

If it contains dur=, parses as ServerTiming format
Otherwise, parses as numeric with optional ms or s suffix

lps httpclient --servertimeheader "Server-Timing" --servertimeformat Auto

Recognized Metric Names

LPS automatically categorizes server timing metrics based on their names. If your server uses different naming conventions, LPS will still recognize them.

Database Metrics (`ServerTimeDB`)

The following names are recognized as database time:

Name	Example Header
`db`	`db;dur=53`
`database`	`database;dur=53`
`mysql`	`mysql;dur=53`
`postgres`	`postgres;dur=53`
`sql`	`sql;dur=53`
`sqlserver`	`sqlserver;dur=53`
`mongodb`	`mongodb;dur=53`
`mongo`	`mongo;dur=53`
`redis-db`	`redis-db;dur=53`
`query`	`query;dur=53`

Cache Metrics (`ServerTimeCache`)

The following names are recognized as cache time:

Name	Example Header
`cache`	`cache;dur=5`
`redis`	`redis;dur=5`
`memcached`	`memcached;dur=5`
`memcache`	`memcache;dur=5`
`varnish`	`varnish;dur=5`
`cdn`	`cdn;dur=5`
`hit`	`hit;dur=5`
`miss`	`miss;dur=5`

Application Metrics (`ServerTimeApp`)

The following names are recognized as application processing time:

Name	Example Header
`app`	`app;dur=120`
`application`	`application;dur=120`
`compute`	`compute;dur=120`
`process`	`process;dur=120`
`processing`	`processing;dur=120`
`handler`	`handler;dur=120`
`controller`	`controller;dur=120`
`logic`	`logic;dur=120`

Total Server Time (`ServerTime`)

The following names are recognized as total server time:

Name	Example Header
`total`	`total;dur=178`
`server`	`server;dur=178`
`response`	`response;dur=178`
`duration`	`duration;dur=178`
`time`	`time;dur=178`
`elapsed`	`elapsed;dur=178`

Aggregation of Multiple Metrics

When your server sends multiple metrics of the same category, LPS sums them together.

Example

If your server returns:

Server-Timing: db;dur=53, mongodb;dur=25, cache;dur=10

LPS will calculate:

ServerTimeDB = 53 + 25 = 78 ms (both db and mongodb are database aliases)
ServerTimeCache = 10 ms
ServerTime = 53 + 25 + 10 = 88 ms (total of all metrics)

This is useful when your application has multiple database calls or cache lookups in a single request.

Another Example

Server-Timing: mysql;dur=30, postgres;dur=20, redis;dur=5, app;dur=100

Results in:

ServerTimeDB = 30 + 20 = 50 ms
ServerTimeCache = 5 ms
ServerTimeApp = 100 ms
ServerTime = 155 ms

Using Server Metrics in Rules

Failure Rules

failureRules:
  - metric: "ServerTimeDB.P90 > 100"      # Fail if DB time P90 exceeds 100ms
  - metric: "ServerTimeCache.Avg > 20"    # Fail if cache avg exceeds 20ms
  - metric: "ServerTimeApp.P95 > 500"     # Fail if app processing P95 exceeds 500ms

Termination Rules

terminationRules:
  - metric: "ServerTimeDB.P90 > 200"
    gracePeriod: "00:00:30"               # Stop test if DB is slow for 30 seconds
  - metric: "ServerTime.P95 > 1000"
    gracePeriod: "00:01:00"               # Stop if total server time exceeds 1s for 1 minute

CLI Usage

lps --url https://api.example.com -rc 1000 --failurerule "ServerTimeDB.P90 > 100" --terminationrule "ServerTime.P95 > 500;00:00:30"

Dashboard Visualization

The LPS dashboard displays all timing metrics in real-time:

Response Time Breakdown: Visual breakdown of TotalTime into TCP, TLS, Waiting, Sending, and Receiving components
Server Timing Panel: Shows ServerTimeDB, ServerTimeCache, ServerTimeApp when available
Percentile Charts: P50, P90, P95, P99 trends over time for all metrics

Best Practices

Add Server-Timing headers to your API: This gives you visibility into backend performance during load tests.
Use consistent naming: Stick to standard names like db, cache, app for clarity.
Include a total metric: Add a total;dur=X entry so LPS can verify the sum matches.
Set appropriate thresholds: Use P90/P95 for SLA-based rules, use Max for catching outliers.
Combine client and server metrics: A high TotalTime with low ServerTime indicates network issues. High ServerTimeDB with low ServerTimeApp points to database optimization needs.

Example: Complete Configuration

name: PerformanceTestPlan
rounds:
  - name: APITest
    numberOfClients: 100
    iterations:
      - name: GetUsers
        httpRequest:
          url: https://api.example.com/users
          method: GET
        
        failureRules:
          - metric: "TotalTime.P90 > 500"
          - metric: "ServerTimeDB.P90 > 100"
          - metric: "ServerTimeApp.P95 > 300"
        
        terminationRules:
          - metric: "ServerTimeDB.P90 > 500"
            gracePeriod: "00:00:30"
          - metric: "ErrorRate > 0.1"
            gracePeriod: "00:00:10"