It seems the issues resolved in the below bugs reoccurring on Satellite 6.16.

https://bugzilla.redhat.com/show_bug.cgi?id=2190509
https://bugzilla.redhat.com/show_bug.cgi?id=2117760

The CV contains filters but dependency resolution is disabled.

1. rpm -qa|grep satellite
   rubygem-foreman_theme_satellite-13.3.2-1.el9sat.noarch
   satellite-installer-6.16.0.2-1.el9sat.noarch
   satellite-maintain-0.0.2-1.el9sat.noarch
   satellite-common-6.16.1-1.el9sat.noarch
   satellite-cli-6.16.1-1.el9sat.noarch
   satellite-6.16.1-1.el9sat.noarch
   satellite-lifecycle-6.16.0-2.el9sat.noarch

After issuing a CV Incremental update, without dependency resolution, only 42% completed in 4 hours. After about 8h19m into the process, it failed with the below exception.

-------
Exception:
Dynflow::Action::V2::WithSubPlans::SubtaskFailedException: A sub task failed
-------

And from the task export:

------
731: Actions::Pulp3::Repository::MultiCopyUnits (success) [ 25185.00s / 181.44s ]
------

Then we cleared all the tasks and performed the below steps.

• removed all unused CVs
• created a CV (4 days ago)
• Tried two CCV creations. They both succeeded. However, they are still taking quite a bit of time. Last one contained:

Errata: RHSA-2025:1372 Packages: buildah-1.33.12-1.module+el8.10.0+22744+7794713b.x86_64 buildah-tests-1.33.12-1.module+el8.10.0+22744+7794713b.x86_64 podman-4.9.4-19.module+el8.10.0+22744+7794713b.x86_64 podman-catatonit-4.9.4-19.module+el8.10.0+22744+7794713b.x86_64 podman-docker-4.9.4-19.module+el8.10.0+22744+7794713b.noarch podman-gvproxy-4.9.4-19.module+el8.10.0+22744+7794713b.x86_64 podman-plugins-4.9.4-19.module+el8.10.0+22744+7794713b.x86_64 podman-remote-4.9.4-19.module+el8.10.0+22744+7794713b.x86_64 podman-tests-4.9.4-19.module+el8.10.0+22744+7794713b.x86_64 runc-1.1.12-6.module+el8.10.0+22722+0028f543.x86_64

And took an hour to complete the CV publish task.

Acceptance Criteria

1. Find average baseline timing for incrementally adding an erratum to a content view with 10 or so repositories (including BaseOS + AppStream). If possible, use a repository set from one of the customers attached to this Jira. Get this with help from the performance team, if possible. Do not enable dependency solving.
2. Document this baseline timing officially.
3. Using this baseline timing with reproducer steps, develop a measurable performance improvement, if possible. I assume this is possible because the code hasn't changed a whole lot for the past few years.