-
Notifications
You must be signed in to change notification settings - Fork 13
Add a test plan for the pulp-worker scalability test. #494
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
Conversation
49aa8be
to
2ebe84d
Compare
|
||
For database, we're using the AWS RDS PostgreSQL 16, on a db.m7g.2xlarge instance class. | ||
In theory, the maximum number of connections is defined by `LEAST({DBInstanceClassMemory/9531392}, 5000)` | ||
as written [here](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Limits.html#RDS_Limits.MaxConnections) |
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.
Maybe, it would be helpful to interpret this with a claim of the total count.
|
||
## Test Plan | ||
|
||
1. Warn the pulp stakeholders (@pulp-service-stakeholders) that a test gonna happen in stage. All tasks must be stopped. |
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.
Realistically we can't ask folks to stop the tasks. I think warning them we're scaling down the memory footprint and their tasks may fail due to memory errors is what they need to know. Also I think they need to know how long the test will run for (how long can they expect failures).
images/assets/patches/0023-Add-the-task-name-to-the-task-log.patch
Outdated
Show resolved
Hide resolved
2. Create a MR reducing the resource for each worker, and increasing the number of workers. [here](https://gitlab.cee.redhat.com/service/app-interface/-/blob/master/data/services/pulp/deploy.yml#L75). | ||
It can be approved by anyone from the team. Just need to wait for the app-sre bot to merge it. | ||
3. After it got merged, check for the database metrics and application logs. The results from the run will be down in this document. | ||
4. We need to check if there's any new worker being started. For that, we need to use the `WorkersAPI` and check a set with the names from time to time. |
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 step needs more detail. To me, it's the whole metric of interest. I'd avoid writing real rigorous code here, and maybe verbally describe the set-name difference "check" and maybe in pseudo-code describe it for clarity for the reader.
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've added an example of a script that can do the job.
090b7bd
to
a4d8f39
Compare
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.
@decko I think this is ready to go! Feel free to merge it and then open up a new MR revising the table once the data is available.
Does that sound ok to you?
No description provided.