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

STORY: As an IMAGE scaling developer, I want to know how many simultaneous requests pegasus can sustain on an ongoing basis, so that we have an idea how much a single server can potentially scale #18

Open
jeffbl opened this issue Sep 19, 2023 · 2 comments
Assignees

Comments

@jeffbl
Copy link
Member

jeffbl commented Sep 19, 2023

No description provided.

@jeffbl jeffbl self-assigned this Sep 19, 2023
@jeffbl jeffbl changed the title As an IMAGE scaling developer, I want to know how many simultaneous requests pegasus can sustain on an ongoing basis, so that we have an idea how much a single server can potentially scale STORY: As an IMAGE scaling developer, I want to know how many simultaneous requests pegasus can sustain on an ongoing basis, so that we have an idea how much a single server can potentially scale Sep 19, 2023
@jeffbl jeffbl transferred this issue from Shared-Reality-Lab/IMAGE-server Oct 5, 2023
@jeffbl
Copy link
Member Author

jeffbl commented Oct 5, 2023

Status at end of Oct02 sprint: Created initial loadtest bash script to use testset.py from the IMAGE-testing repo to make requests at regular intervals, to see what breaks. Next steps for Oct23 sprint:

  • figure out what actual errors are happening, and what they mean (e.g., watch logs, check request responses)
  • integrate further into existing test scripts, e.g., for selecting subset of photos to use in test, instead of explicitly listing by number

@jeffbl
Copy link
Member Author

jeffbl commented Oct 26, 2023

Status at end of Oct23 sprint: Clear that to do comparisons of correct resultsand what comes back from heavily loaded server will require using existing test scripts, since there will be trivial differences (e.g., timestamps) that will make a naive compare fail even when results are correct. Teasing apart the scripts to work well for this testing will require more time. Importance of server scaling is reduced for upcoming grant, so moving to backlog until this becomes more pressing.

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

No branches or pull requests

2 participants