Pulp

Ticket moved to GitHub: "pulp/pulpcore/1902":https://github.com/pulp/pulpcore/issues/1902

Pulp 3 has a more complicated architecture on the externally-facing side than Pulp 2 does. Whereas Pulp 2 wrote directories of symlinks and relied on a web server (Apache) to serve them as a static directly, Pulp 2 has a custom app which services incoming requests by matching their paths against paths stored in the database.

This means that as the # of clients being simultaneously served scales up, so too does the load on the database. We should measure this impact to gain an understanding of how Pulp 3 is likely to behave in a real-world scenario where many thousands of clients may be requesting packages from a Pulp installation and, concurrently, Pulp administrative tasks such as sync and publish may be loading the database as well.

One possible way of testing this would be to create a Kubernetes cluster of "package consumer" agents which can be scaled as desired for the testing.

We would also need some kind of monitoring - but I do not have any suggestions on how this should be accomplished.

This testing should occur in advance of any dev-freeze date, so that we have time to make adjustments if they are found to be necessary.