Skip to content
This repository has been archived by the owner on Feb 1, 2024. It is now read-only.

Update tile load test script and add scripts for hompage load, facility download, and facility POST #1777

Merged
merged 8 commits into from May 20, 2022

Conversation

jwalgran
Copy link
Contributor

@jwalgran jwalgran commented Mar 26, 2022

Overview

Update tile load test script and add scripts for hompage load, facility download, and facility POST

Connects #1776

Testing Instructions

NOTE these scripts have been successfully used on staging so this can be a cursory review.

  • Register an account on staging and generate an API token
  • Obtain the CLIENT_KEY used on staging
  • cd into the load-tests directory.
  • Verify that you can run the new load test commands added to the README in the PR

Checklist

  • fixup! commits have been squashed
  • CI passes after rebase
  • CHANGELOG.md updated with summary of features or fixes, following Keep a Changelog guidelines

Comment on lines 58 to 61
buildGet(`${rootUrl}/static/css/2.037bc208.chunk.css`),
buildGet(`${rootUrl}/static/css/main.cfc7f5ef.chunk.css`),
buildGet(`${rootUrl}/static/js/2.b90b8892.chunk.js`),
buildGet(`${rootUrl}/static/js/main.058b1d83.chunk.js`),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are going to be different for each release. I think the way to get these dynamically is to search the HTML returned from a request to /

@jwalgran jwalgran changed the title Update tile load test script and add scripts for hompage load and facility download Update tile load test script and add scripts for hompage load, facility download, and facility POST Mar 28, 2022
@jwalgran jwalgran marked this pull request as ready for review April 29, 2022 19:18
Copy link
Contributor

@emilyhu0106 emilyhu0106 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tests looks very good! Wondering if below is the expected output for the facility POSTing test?

  execution: local
     script: /scripts/post_facility.js
     output: -

  scenarios: (100.00%) 1 scenario, 5 max VUs, 10m30s max duration (incl. graceful stop):
           * default: 5000 iterations shared among 5 VUs (maxDuration: 10m0s, gracefulStop: 30s)


running (03m34.3s), 0/5 VUs, 5000 complete and 0 interrupted iterations
default ✓ [======================================] 5 VUs  03m34.6s/10m0s  5000/5000 shared iters

     ✗ is status 2xx
      ↳  0% — ✓ 0 / ✗ 5000

     checks.....................: 0.00%   ✓ 0         ✗ 5000
     data_received..............: 2.0 MB  9.2 kB/s
     data_sent..................: 1.3 MB  6.2 kB/s
     http_req_blocked...........: avg=388.49µs min=25.3µs   med=35.4µs   max=342.4ms  p(90)=76.71µs  p(95)=113.3µs 
     http_req_connecting........: avg=88.7µs   min=0s       med=0s       max=92.85ms  p(90)=0s       p(95)=0s      
     http_req_duration..........: avg=213.29ms min=144.79ms med=199.96ms max=4.64s    p(90)=232.73ms p(95)=254.86ms
     http_req_failed............: 100.00% ✓ 5000      ✗ 0   
     http_req_receiving.........: avg=301.9µs  min=69.3µs   med=192.5µs  max=22.68ms  p(90)=439.34µs p(95)=664.28µs
     http_req_sending...........: avg=326.84µs min=118.7µs  med=287.7µs  max=1.8ms    p(90)=496.43µs p(95)=603.02µs
     http_req_tls_handshaking...: avg=134.93µs min=0s       med=0s       max=138.33ms p(90)=0s       p(95)=0s      
     http_req_waiting...........: avg=212.66ms min=143.8ms  med=199.35ms max=4.64s    p(90)=232.06ms p(95)=254.3ms 
     http_reqs..................: 5000    23.327565/s
     iteration_duration.........: avg=214.48ms min=179.94ms med=200.66ms max=4.98s    p(90)=233.45ms p(95)=255.38ms
     iterations.................: 5000    23.327565/s
     vus........................: 5       min=5       max=5 
     vus_max....................: 5       min=5       max=5 

I also did some readings about k6 and load tests, reviewing this PR is helpful!

@jwalgran
Copy link
Contributor Author

jwalgran commented May 4, 2022

Sorry for the delayed response on your comment. The POST test output your shared shows that all the requests responded with a status other than 200, which is not correct.

That script does require that TOKEN is set to a valid API token from staging. Did you run the command with a token from a staging account? If not, I can share my staging token with you that is configured for unlimited staging API access

 TOKEN=abc123-some-real-token-here \
docker-compose -f docker-compose.yml \
  run --rm k6 run -u 5 -i 5000  /scripts/post_facility.js

@emilyhu0106
Copy link
Contributor

I just ran this test twice with a staging API Token.

The first time failed in the middle of the tests, probably due to api limits. The result is as below:

running (10m02.3s), 0/5 VUs, 1463 complete and 0 interrupted iterations
default ✗ [==========>---------------------------] 5 VUs  10m03.0s/10m0s  1463/5000 shared iters

     ✗ is status 2xx
      ↳  96% — ✓ 1405 / ✗ 58

Then I gave myself unlimited api calls, ran it again. It was complete but failed

running (03m09.4s), 0/5 VUs, 5000 complete and 0 interrupted iterations
default ✓ [======================================] 5 VUs  03m09.6s/10m0s  5000/5000 shared iters

     ✗ is status 2xx
      ↳  0% — ✓ 0 / ✗ 5000

Should I try with another API token?

@jwalgran jwalgran closed this May 5, 2022
@jwalgran jwalgran reopened this May 5, 2022
@jwalgran
Copy link
Contributor Author

jwalgran commented May 5, 2022

I clicked the "close" button by accident.

@jwalgran
Copy link
Contributor Author

jwalgran commented May 5, 2022

I scheduled a pairing session on Friday May 6 to look at this together.

Copy link
Contributor

@emilyhu0106 emilyhu0106 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All tests are passed after the pairing. It was related to the API blocks that can be updated in the Admin Dashboard. Thank you Justin!

Allows for testing tile requests for different facility filters, some of which
may be more expensive than others.
Ensures that the requests in parallel runs using VU_MULTIPLIER do not line up.
Attempting to make a more realistic test.
The tile load test uses virtual users and iterations to chunk and run requests
read from a HAR file and exists after one set of tile requests is done. This
helper loops a run of the scripts with a different CACHE_KEY_SUFFIX for each run
to allow for testing sustained continuous load.
This script was initially created by browsing the home page, exporting the
requests as a HAR file, converting the HAR file to a script using k6.io, then
modifying the script to simulate the parallel request behavior of a browser.

Making API requests requires a CLIENT_KEY so we update the load testing compose
file to pass through an appropriate environment variable.
Mimics the process used by the application to load a page of facilities at a
time. Calling the API requires setting the CLIENT_KEY environment variable.
FILTERS can be set to change the query string arguments passed to each page
request.
Includes definitions of all supported env vars and examples of how to run each
of the load test scripts.
To simulate API partners POSTing a list of facilities to the API.

`addresses.csv` was generated by downloading facility addresses from the staging
data set.

Portions of the random-ish facility name generator were adapted from
https://github.com/joke2k/faker/blob/5b98d2ab877e414b51e76abc8fdde2fb2dad6710/faker/providers/company/__init__.py
@jwalgran
Copy link
Contributor Author

Thanks for the review.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants