Load testing seems to start - but does not test the specified routes

[mjovanc]

Hi, according to your instructions when implementing this in my GitHub Actions workflow I get some strange output. It doesn't show which URL is being targeted and I think it's targeting the base URL since I have setup the base URL to produce a 404 error because I don't use a rendering engine. But the API paths should be targeted and produce 200 and be tested, but that doesn't seem to work. I use Express as the framework.

This is the output I get until it timeouts:

> node server.js

npm WARN exec The following package was not found and will be installed: wait-on
Server started on http://localhost:3000
Press Ctrl-C to terminate...
HEAD / 404 6.135 ms - 19
HEAD / 404 1.606 ms - 19
HEAD / 404 1.269 ms - 19
HEAD / 404 1.325 ms - 19
HEAD / 404 1.148 ms - 19.
HEAD / 404 1.458 ms - 19
HEAD / 404 1.066 ms - 19

My loadTest.js file:

import http from 'k6/http'
import { check, group, sleep } from 'k6'

export const options = {
  stages: [
    { duration: '5m', target: 100 }, // simulate ramp-up of traffic from 1 to 100 users over 5 minutes.
    { duration: '10m', target: 100 }, // stay at 100 users for 10 minutes
    { duration: '5m', target: 0 }, // ramp-down to 0 users
  ],
  thresholds: {
    'http_req_duration': ['p(99)<1500'], // 99% of requests must complete below 1.5s
  },
}

const BASE_URL = 'http://localhost:3000';

export default () => {
  const allPosts = http.get(`${BASE_URL}/api/v1/posts`).json()
  check(allPosts, { 'retrieved posts': (obj) => obj.length > 0 })

  const allCategories = http.get(`${BASE_URL}/api/v1/categories`).json()
  check(allCategories, { 'retrieved categories': (obj) => obj.length > 0 })

  sleep(1)
}

This is my GitHub workflow:

name: Load Testing

on: push
#  schedule:
#    - cron: '*/15 * * * *'

jobs:
  test:
    name: k6 Load Test
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:latest
        env:
          POSTGRES_DB: prod
          POSTGRES_USER: postgres
          POSTGRES_PASSWORD: test1234
        ports:
          - 5432:5432
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
    
    env:
      NODE_ENV: production
      DATABASE_URL: postgres://postgres:test1234@0.0.0.0:5432/prod

    steps:
      - name: Checkout
        uses: actions/checkout@v1

      - name: Install k6
        run: |
          curl https://github.com/loadimpact/k6/releases/download/v0.26.2/k6-v0.26.2-linux64.tar.gz -L | tar xvz --strip-components 1
      
      - name: Install Packages
        run: |
          npm install
      
      - name: Start Server and Run Tests
        run: |
          npm start & npx wait-on http://localhost:3000
          ./k6 run tests/k6/loadTest.js

Perhaps I might have misunderstanding the usage of this test JS file that I built, but I used examples of https://k6.io/docs/using-k6/thresholds/ to test different ones with same result.

[mstoykov]

Hi @mjovanc, from wait-on documentation it seems to be waiting to get 200 (status ok) on HEAD before it stops.

So basically you block on npm start & npx wait-on http://localhost:3000 and never even execute k6.

I would also recommend to not use a version of k6 that is now over 2 years old ;)

I will be closing this issue, as given the above it's completely unrelated to the k6 action.

If you think otherwise please comment, or if you have an additional problem - please open a new issue.

[samesfahani-tuplehealth]

@mstoykov I have maybe a somewhat related question about the wait-on recipe that you may be able to help with.

I have something running along the lines of:
npm start-server & wait-on http://localhost:8080 && k6 run src/load-testing/test.js

The server starts, wait-on eventually kicks in and starts k6, and my tests finish. However, nothing is telling the server to stop at this point and the action runs indefinitely. Is there some clever way I can stop the server once my k6 tests are finished? I'd really rather not pull out the kitchen sink here with a process manager of sorts or write a script to spawn a child process.