Reliability and performance tests

Runnable example of smoke test

1 min

Script and how to run

The following script, executed with tool k6 , simulates a basic smoke test:

script.js

import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
  vus: 1,
  duration: '20s',
};

export default function () {
  const url = 'https://quickpizza.grafana.com';

  // valid address
  http.get(`${url}`);
  sleep(1);

  // address not available
  // k6 shows warning no such host
  http.get(`${url}.local`);
  sleep(1);

  // valid address but server returns 404
  // k6 will treat this as request failed and output it in percentage of failed requests (not showing any warning))
  http.get(`${url}/example.php`);
  sleep(1);

  // valid address
  http.get(`${url}/contacts.php`);
  sleep(1);

  // valid address
  http.get(`${url}/news.php`);
  sleep(1);
}

Install tool k6 and download script.js , then run it locally with:

  k6 run script.js

Analysis

After being run k6 produces result .

 
Info

To better understand the terms in testing and tool k6 see vocabulary.

Test summary
  • 1 virtual user (VUs: 1)
  • duration: 20 seconds
  • scenario: multiple requests to different URLs with sleep(1) after each request
Observed behavior

Successful requests:

Failing requests (DNS resolution failures):

Failing requests (404):

Metrics highlights
  • http_req_failed: 40% (4 of 10 requests failed):
    2 due to DNS resolution errors (no such host), 2 due to 404
  • Throughput:
    http_reqs: 10 total requests, 0,465 req/s request rate
  • Response times for successful requests:
    avg = 104,34 ms, p(90) = 132,22 ms, p(95) = 132,82 ms — these are all well below the common threshold of 300 ms which is a good latency
  • Iteration duration:
    ~10,74 s per iteration (due to sleep(1) calls after each request)
Data transferred
  • 17 KB received
  • 2,2 KB sent

Consistent with a low-traffic single-user test.

Overall analysis

The test worked exactly as coded:

  • k6 correctly logged DNS resolution errors as warnings,
  • 404 responses were counted as http_req_failed (this behavior can be customized using check() to treat 404s as acceptable, if desired),
  • latency for valid requests was very good (~110 ms on average).

Script produced 10 requests in total, across 2 iterations, each iteration lasting ~10,76 s due to deliberate sleep(1) pauses.

Suggestions and takeaways
  • To treat specific status codes as acceptable (e.g. 404), check() can be used with custom conditions.
  • DNS issues should be addressed unless introduced deliberately.
  • Performance was solid — no latency concerns under these test conditions.