-
Notifications
You must be signed in to change notification settings - Fork 12
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
Added load test to generate traffic for green check API tests in Gree… #591
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.js Anyway, 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_tmp Then 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-checks The 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