- 
                Notifications
    You must be signed in to change notification settings 
- Fork 15
Added load test to generate traffic for green check API tests in Gree… #591
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: sl-gmt
Are you sure you want to change the base?
Conversation
| When I try to run the GMT tool locally, even without these changes, I get the following error output - I'm sure this is a local config issue: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 0_o >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Traceback (most recent call last): <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 0_o >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Error: Command failed Stdout (<class 'str'>): The above exception was the direct cause of the following exception: Traceback (most recent call last): Run_id (<class 'uuid.UUID'>): 02946e27-6a96-4245-9198-0b48e5f7dbc8 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 0_o >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> | 
| I @jcamilleri-scottlogic - I've had a look at this I'm unable to reproduce the database connection issues but I did come across a different issue that I think would stop this working. Previously the load testing script looked like this: export default function () {
  // define URL and request body
  const url = "https://django:9000/api/v3/greencheck/climateaction.tech";
  const params = {
    headers: {
      "Content-Type": "application/json",
    },
  };
  // send a post request and save response as a variable
  const res = http.get(url, params);
  // check that response is 200
  check(res, {
    "response code was 200": (res) => res.status == 200,
  });
}I'll the changes I've made to my usage scenario do you can sanity check against yours. It's a big long, do I've hidden it inside a expandable details block Details
 the main change I have from yours is that I am using a volume mount for copying the  ---
name: Greencheck Test
author: James Camilleri <[email protected]>, Chris Adams <[email protected]>
description: Scenario to test the Greencheck endpoint of the Green Web Foundation Greencheck API
version: "3.5"
networks:
  greencheck-network:
services:
  mariadb:
    image: mariadb:10.11
    ports:
      - 3306:3306
    environment:
      - MYSQL_ROOT_PASSWORD=deploy
      - MYSQL_DATABASE=greencheck
      - MYSQL_USER=deploy
      - MYSQL_PASSWORD=deploy
    networks:
      - greencheck-network
  rabbitmq:
    image: rabbitmq:3.11
    restart: always
    ports:
      - 5672:5672
    options: '--hostname "rmq" --health-cmd "rabbitmqctl status" --health-interval 10s --health-timeout 10s --health-retries 3 --health-start-period 60s'
    networks:
      - greencheck-network
  django:
    image: greenweb-app
    depends_on:
      - mariadb
      - rabbitmq
    # if we have the greenweb-app container built, commenting out the lines below
    # means we can use the image we've already built rather than needing to take a
    # few minutes each time to build it fresh again
    # build:
    #   context: .
    #   dockerfile: Dockerfile
    # if we need to inspect the container, and make changes between runs
    # mounting the volumes below allows for change to the most commonly
    # changed files without needing to rebuild the container
    # volumes:
    #   - ./apps:/app/apps
    #   - ./greenweb:/app/greenweb
    # we use sleep 5 as a hack to wait for the database to be ready
    setup-commands:
      - sleep 5
      - python manage.py migrate
      - python manage.py collectstatic --noinput
    environment:
      - PORT=9000
      - GUNICORN_BIND_IP=0.0.0.0
      - PYTHONDONTWRITEBYTECODE=1
      - PYTHONUNBUFFERED=1
      - DATABASE_URL=mysql://deploy:deploy@mariadb:3306/greencheck
      - DATABASE_URL_READ_ONLY=mysql://deploy:deploy@mariadb:3306/greencheck
      - RABBITMQ_URL=amqp://guest:guest@rabbitmq:5672/
      - DJANGO_SETTINGS_MODULE=greenweb.settings.development
    ports:
      - 9000:9000
    # uncomment this be able to send requests to the django container
    # from outside the docker network
    # expose:
    #   - 9000
    # restart: on-failure
    log-stdout: true
    log-stderr: true
    networks:
      - greencheck-network
  # test-container:
  #   container_name: test-container
  #   image: node
  #   log-stdout: true
  #   log-stderr: true
  #   depends_on:
  #     - django
  #   setup-commands:
  #     - cp /tmp/repo/green_metric_tests/greencheck_test.spec.js .
  #     - cp /tmp/repo/green_metric_tests/package.json .
  #     - npm install
  #   networks:
  #     - greencheck-network
  load-test-container:
    container_name: load-test-container
    log-stdout: true
    log-stderr: true
    image: grafana/k6
    depends_on:
      - django
    # setup-commands:
    #   - cp /tmp/repo/green_metric_tests/greencheck_api_loadtest.js /src/greencheck_api_loadtest.js
    networks:
      - greencheck-network
    volumes:
      - ./green_metric_tests:/src
flow:
  # this should trigger a http request to an API endpoint
  # of http://django:9000, simulating a greencheck lookup
  # - name: Greencheck API Test
  #   container: test-container
  #   commands:
  #     - type: console
  #       command: npm test
  #       note: Starting test
  #       read-notes-stdout: true
  #       log-stdout: true
  #       log-stderr: true
  #     - type: console
  #       note: Idling
  #       command: sleep 30
  #     - type: console
  #       command: npm test
  #       note: Starting test again
  - name: Greencheck API Load Test
    container: load-test-container
    commands:
      - type: console
        note: Starting load test
        log-stdout: true
        log-stderr: true
        read-notes-stdout: true
        command: k6 run --iterations 11 /src/greencheck_api_loadtest.jsAnyway, a key thing I saw was that the load test was trying to connect to  When I shell into the load testing container like so once all the containers are booted: docker run -it --rm \
  --name load-test-container-<UNIQUE_SLUG>  \
  --entrypoint /bin/sh \
  -v /Users/chrisadams/Code/tgwf/gmt-testing-admin-portal:/tmp/repo:ro \
  -v /Users/chrisadams/Code/tgwf/gmt-testing-admin-portal/green_metric_tests:/src \
  --net greencheck-network grafanak6_gmt_run_tmpThen I can manually run the following command, and see the output: To get a shell, I had to override the entrypoint with  I've linked what I think is the dockerfile for k6 - this is where I figured out what the entry point might be: I'll share the annotated output from running this usage scenario, as I think there may be something up with the actual command used to run the load test from that file. Details
 This is calling the following command from the Green Metric Repo inside  python3 runner.py \
  --uri /Users/chrisadams/Code/tgwf/gmt-testing-admin-portal \
  --name testing-fresh-greenweb  \
  --allow-unsafe \
  --print-logs \
  --dev-no-metrics \
  --dev-no-sleeps \
  --dev-no-build \
  --skip-system-checksThe rest is what I would expect So far, this is ok. We are setting up rabbit mq, our mariadb database server, and the django server, then running migrations to set up the desired database state, and collect all the static files so they can be served from a single directory. The next bit is the load-test-container using k6. this is what I based the command above to log into a comparable container and troubleshoot. The key difference was removing the  The next  steps are carrying out the steps in the flow. For clarity I commented out the other  Here's where we are seeing errors - on boot, calling  The logs below are not errors but they are output sent to STDERR. It might make sense to pass a  Here is the output from calling  From what I can see, it looks like load-test-container is not calling k6 to run the load test like we saw above when I run it manually. I'm not sure why that's happening because I assumed that 
 And this command inside would be functionally the same: Instead we're seeing the output from the django server ready to receive requests, and then the output from k6 when you run k6 with no other arguments: We have some time booked today anyway, but hopefully this provides a bit more context, and helps along the way. | 
| Hi @ArneTR - just quick one before we go further on this. GMT doesn't have any native load testing tooling inside it, right? @jcamilleri-scottlogic is working trying to recreate conditions of hitting an endpoint multiple times a second, a bit like how the app works in production, and we're not sure if this a sensible way to use GMT. We're not trying to recreate production exactly, obvs, but at least have a scenario that's more representative of a just single HTTP request in isolation | 
| Hey @mrchrisadams , no GMT does not have an integrated load testing tool. But it is designed to support any tool that you have. We have many people using GMT in that fashion. A typical tool in the java world is for instance jMeter and in essence you would just start a container alongside your others on the system and stress your API. See an example here: https://github.com/green-coding-solutions/example-applications/tree/main/jmeter I do not know which load tester you have in mind but for a simple HTTP(S) API I would probalby go for a CLI based one like ab Happy to support more and do not hesitate to follow up | 
…n Metric Tool