-
Notifications
You must be signed in to change notification settings - Fork 13
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
[Issue #2473] Add new artillery #2723
Conversation
7a8ee66
to
7ebdf35
Compare
9d40c93
to
02bb8d4
Compare
5ea0d38
to
6db3d0c
Compare
"dev": [], | ||
"prod": [] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
staging too please! I'll be indexing the load test numbers off staging rather than dev
context.vars.$environment === "stage" ? "dev" : context.vars.$environment; | ||
const envs = new Set(["local", "dev", "prod"]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this line too, staging 🙏🏼
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm treating dev and stage as the same since the data is the same. If you use the stage
flag is uses the dev
data but still uses the stage routes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's valid, but I feel like nobody is going to figure that out and then assume that we never load test in staging :/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated it.
{ | ||
percent: 50, | ||
params: [qu, st, pager], | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
qu, st, pager
what do these mean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I put a little more explanation into the desc. This composes the query so that 50% of the requests use a query term, pager, and status selected...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I see it now, can we use the full name though pls? rg. eligibility
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated it to be more verbose.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
local setup done 🙏🏼
Summary
Fixes #2473
Time to review: 5 mins
Changes proposed
This adds a
processor.ts
file for running load tests runs get requests for opp pages, search pages, static pages, and 404 pages.To test locally,
artillery run -e local artillery-load-test.yml
. This only runs a few requests locally but you can see the log messages and check your local frontend server to see the results.For the search page requests, there is a rudimentary algo that decides how many requests are just a search verse using all of the filters: https://github.com/HHS/simpler-grants-gov/pull/2723/files#diff-7aa6fd7f8d487e65e1da7d5a1407eafa7eb5f62bb4443621048e6d025c23f75fR62 Currently, 50% of the requests use a search query and pager, 20% use those and an agency, etc. This is hard coded. If we find we want to update that we can pull those weights into the yaml file, but didn't seem like worth the effort for now.