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

Avoid the puppet clj-http-client in benchmark to improve performance #3886

Closed
rbrw opened this issue Oct 4, 2023 · 0 comments
Closed

Avoid the puppet clj-http-client in benchmark to improve performance #3886

rbrw opened this issue Oct 4, 2023 · 0 comments
Assignees

Comments

@rbrw
Copy link
Contributor

rbrw commented Oct 4, 2023

Just use the JDK client. Some previous investigations have suggested that the puppet client has performance issues (at least the sync client), and recent pdb benchmarking has implied something similar -- it could only emulate about 80k hosts with a 30s run interval, no matter how many senders or similation threads it had (on a large 32-core server).

Since benchmark only needs to make synchronous POSTs from existing threads (the senders), the JDK's built in client should work fine, and preliminary tests have been promising.

We'll need to continue to support ssl-certs via pem files, but we can use puppet's ssl-utils for that.

@rbrw rbrw self-assigned this Oct 4, 2023
rbrw added a commit to rbrw/puppetdb that referenced this issue Oct 5, 2023
Some previous investigations have suggested that the puppet client has
performance issues (at least the sync client), and recent pdb
benchmarking has implied something similar -- it could only emulate
about 80k hosts with a 30s run interval, no matter how many senders or
simulation threads it had (on a 60-core, non-hyperthreaded server).

We suspect the puppet client may be adding extra complexity by
(if nothing else) emulating sync via its async client (rather than
just using the Apache sync client directly), and since benchmark only
needs to make synchronous POSTs from existing threads (the senders),
switch to the straightforward JDK client.

Preliminary testing was promising, and after fully implementing this,
benchmark was able to emulate over 140k hosts on the server mentioned
above, using the same randomization percentage of 100.  Guessing that
we might now be hitting a CPU constraint, we changed the randomization
to 10 percent, and were able to emulate at least 200k hosts.

Fixes: puppetlabs#3886
rbrw added a commit to rbrw/puppetdb that referenced this issue Oct 10, 2023
Some previous investigations have suggested that the puppet client has
performance issues (at least the sync client), and recent pdb
benchmarking has implied something similar -- it could only emulate
about 80k hosts with a 30s run interval, no matter how many senders or
simulation threads it had (on a 60-core, non-hyperthreaded server).

We suspect the puppet client may be adding extra complexity by
(if nothing else) emulating sync via its async client (rather than
just using the Apache sync client directly), and since benchmark only
needs to make synchronous POSTs from existing threads (the senders),
switch to the straightforward JDK client.

Preliminary testing was promising, and after fully implementing this,
benchmark was able to emulate over 140k hosts on the server mentioned
above, using the same randomization percentage of 100.  Guessing that
we might now be hitting a CPU constraint, we changed the randomization
to 10 percent, and were able to emulate at least 200k hosts.

Fixes: puppetlabs#3886
@rbrw rbrw closed this as completed in dc2033c Oct 11, 2023
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

1 participant