I've extracted the reposet enable code into more dynflow actions to have more numbers in hand:
1. load initial data to be able to start scanning: 2s
2. the scanning of cnd itself: 3.5s
3. create 12 repos locally in db: 16 s: majority of the time, it was the repository.save itself
4. create 12 repos in pulp in parallel (7 s total, in scale of 3-7s: most of the time it was the distributor publish stuff)
This gives us around 30s for repo set enable.
This is already boost comparing the old style, where the repo creation (both local db and pulp orchestration) was run
in sequence, which gives us more than 60s for the task.
Possible optimization are:
1. run even the local repo creation in parallel (would give us around - 10s)
2. disable the metadata genration after repo is created (as we don't need that until some content appears there anyway) (would give us around -8s)
3. postpone the repo creation to the repo-enable phase (would give us - -25s) it would be just about loading the listing files from cdn, which takes around 5 seconds. Later optimization could be
My favorite is the option 3. and now is good time to do this change, we need to add the support for repo-enable in new cli so we will touch the code anyway.