-
Notifications
You must be signed in to change notification settings - Fork 42
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
Speed up uploads by uploading chunks in parallel #263
Comments
There was another request from the services team to make the uploading happen in parallel. I am a bit sceptical about this idea because we usually saturate the uplink with uploading in serial. However, there might be data centers where this saturation cannot be reached because of reverse-proxy configurations disallowing a larger chunk size. I am going to introduce an option to the upload/artifact command that enables parallelism (e.g., |
You may want to make the number of parallel threads or processes configurable somehow as I imagine different Pulp instances could support different levels of throughput. |
Doing uploads in parallel requires adding some notion of parallel execution into the cli codebase (that has been unprecedented). I would like to see some clear statements with numbers before gauging the need for adding this kind of complexity to the project. I.e. I cannot say, whether pulp-glue is thread safe. Do we want to rewrite it in async python, using aiohttp instead of requests? |
I made a couple of experiments locally (using oci_env) and here are the results. It appears that uploading chunks in parallel improved the performance by 50%. I did not spend much time writing quality code or using any optimization techniques besides splitting an uploaded file into 4 chunks and then uploading those chunks in sub-chunks in parallel. Test 1: With creating an artifact (db reset between runs, uploading one commit in a tarball, 717.7MB, 10MB chunks)
Test 2: Without creating an artifact (db reset between runs, uploading one commit in a tarball, 717.7MB, 10MB chunks)
Changes made to pulp-glue: https://gist.github.com/lubosmj/1d736226c1816fb019430e7fb78cdd55. Changes made to pulp-cli-ostree: https://gist.github.com/lubosmj/3bc14338713ab9a55343359ff49829b1. I used processes (https://pypi.org/project/multiprocess/ for easier function pickling) to perform the action. |
TCP congestion control is designed to manage the flow of data to prevent network congestion and ensure fairness among multiple connections. However, this mechanism primarily operates on a per-connection basis. This is what we are trying to bypass by uploading in parallel, right? Multiple TCP connections from a single host can then easily saturate the uplink. |
The following experiment supports that theory. When uploading commits to staging, I am getting amazing results. Almost 4-times better performance, seeing the speed of uploads and used uplink. Test 1: Serial uploading (1MB chunk, 1 TCP connection, 1.3GB in total)
Test 2: Parallel uploading (1MB chunk, 4 parallel processes, 4 TCP connections, 1.4GB in total)
Tested with the following changes applied on the respective main branches: lubosmj@8d57381, lubosmj/pulp-cli-ostree@0c4f3ae. OSTree commits were taken from https://autosd.sig.centos.org/AutoSD-9/nightly/ostree-repos/. |
Right now chunk uploads happen sequentially but we could speed them up running them in parallel.
The text was updated successfully, but these errors were encountered: