Skip to content
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

Upload API stress/load testing #88

Open
4 of 5 tasks
mkrystof opened this issue May 5, 2023 · 5 comments · Fixed by CDCgov/data-exchange-api-examples#27
Open
4 of 5 tasks

Upload API stress/load testing #88

mkrystof opened this issue May 5, 2023 · 5 comments · Fixed by CDCgov/data-exchange-api-examples#27
Assignees
Labels

Comments

@mkrystof
Copy link
Collaborator

mkrystof commented May 5, 2023

Stress test the following scenarios:


  • Test DEX -> EDAV copy by azure function for large payloads

Note: please see test results below.

@rmharrison
Copy link
Collaborator

Re: large file uploads

Single large file upload
Simultaneous large file uploads

Flagged by Frank Wang

Azure function is limited to 10 min execution, right? I am thinking about larger datasets especially all CDC data coming in using the Upload API and Functions may overload.

We're using a higher-tier, so we don't have a 10 min execution limit. But it's possible than an Azure Function timeout could kill the copy. It depends on whether the function is waiting for a synchronous copy complete response, or just triggers the copy (async). I'm not sure how it's implemented.

@cosmycx
Copy link
Collaborator

cosmycx commented May 31, 2023

File Name File Size Upload Duration [ms] Upload Duration [s] Note
large_file_95MB.txt 95MB 25205 25.205
large_file_95MB.txt 95MB 46841 46.841
large_file_95MB.txt 95MB 24303 24.303
large_file_95MB.txt 95MB 8878 8.878
large_file_95MB.txt 95MB 28440 28.44 concurrent upload
large_file_190MB.txt 190MB 45984 45.984
large_file_190MB.txt 190MB 70151 70.151
large_file_190MB.txt 190MB 35144 35.144
large_file_190MB.txt 190MB 39293 39.293
large_file_190MB.txt 190MB 52680 52.68 concurrent upload
large_file_476MB.txt 476MB 931273 931.273 not on z-scaler, received response patch 500 once
large_file_476MB.txt 476MB 32093 32.093 on z-scaler
large_file_476MB.txt 476MB 30174 30.174 on z-scaler
large_file_476MB.txt 476MB 91478 91.478 not on on z-scaler
large_file_953MB.txt 963MB 261317 261.317 (~4.35 min) on on z-scaler
large_file_4GB.txt 4GB 2212094 2212.094 (~36 min) on z-scaler, received responses patch 500, head 423, upload resumed
large_file_5.56GB.txt 5.56GB 2733818 2733.818 (~45 min) on z-scaler, received multiple responses patch 500, see pics below, upload resumed but lost chunks, eventually and finished

@cosmycx
Copy link
Collaborator

cosmycx commented Jun 2, 2023

For large files, usually larger than 4GB, the upload grinds and restarts in the back:

perf_4GB_back_resume_2
perf_4GB_back_resume_3
perf_4GB_back_resume_4
image

@rmharrison
Copy link
Collaborator

Thx @cosmycx. This is fine for individual file, but doesn't really cover the "one client, many concurrent files" use case.
It looks like you did concurrency of 2x.
A concurrent file test would cover 2-100x files. Sparse is fine [2, 3, 5, 8, 13, 21, 34, 55, 89...].
My current understanding is concurrency fails at ~4.

@cosmycx
Copy link
Collaborator

cosmycx commented Jun 5, 2023

changed function plan:
image
looks to be working differently and crashing less, still getting 500s
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
4 participants