Skip to content

Figure out how DevWorkspace operator / webhooks server responds to heavy load #398

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

Closed
amisevsk opened this issue Apr 27, 2021 · 1 comment
Assignees
Labels
sprint/current Is assigned to issues which are planned to work on in the current team sprint
Milestone

Comments

@amisevsk
Copy link
Collaborator

Description

Since the DevWorkspace operator adds webhooks for pods/exec, we need to stress-test the webhooks server (and to a lesser extent, the controller itself) to get a sense of what effect deploying this to a big cluster would have. This is crucial since every time the webhooks server crashes, all pods/exec requests are blocked until it comes back up.

  1. What memory/cpu limit is required by the webhooks server to allow it to handle a given amount of pods/exec requests on a cluster?
  2. How is throughput affected when the webhooks server is under load? Are we delaying every pods/exec significantly when we're under load?

Part of the difficulty in testing this is getting a reasonable estimate of how many requests we should actually expect.

@tinakurian tinakurian self-assigned this May 25, 2021
@sleshchenko sleshchenko added sprint/current Is assigned to issues which are planned to work on in the current team sprint and removed sprint/next labels May 26, 2021
@sleshchenko sleshchenko added this to the v0.6.0 milestone Jun 16, 2021
@sleshchenko
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sprint/current Is assigned to issues which are planned to work on in the current team sprint
Projects
None yet
Development

No branches or pull requests

3 participants