[Pulp-dev] Pulp3 Concurrency testing

David Davis daviddavis at redhat.com
Tue Jul 28 15:44:51 UTC 2020

Today we discussed this at triage. We're leaning towards changing the
default from 20 to 10 as it seems like 10 only incurs an extra 30% penalty
in time while seeming to fix the problem[0].

One question though is how we should treat existing data because most
Remotes at this point probably have a value of 20 for download_concurrency.
We came up with two options that we would like some feedback on.

# Option 1: Migrate 20 to 10

This would be a migration in pulpcore that would update
download_concurrency to 10 for all Remotes whose download_concurrency is
set to 10. Something like:


# Option 2: Documentation

This would be similar to the migration approach but instead of modifying
our users' data, we'd document how they could do it themselves. So
something like:

    pulpcore-manager shell_plus -c

Any feedback is welcome.

[0] https://pulp.plan.io/issues/7186#note-2


On Mon, Jul 27, 2020 at 2:57 PM Grant Gainey <ggainey at redhat.com> wrote:

> Hey folks,
> Looking into issue 7212 <https://pulp.plan.io/issues/7212> , over the
> weekend I did some ad-hoc evaluations of sync-performance at various
> concurrency settings. I wrote up my observations here:
> https://hackmd.io/@ggainey/pulp3_sync_concurrency
> Just thought folk might be interested.
> G
> --
> Grant Gainey
> Principal Software Engineer, Red Hat System Management Engineering
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20200728/ce99caee/attachment.htm>

More information about the Pulp-dev mailing list