-
Notifications
You must be signed in to change notification settings - Fork 2.2k
(PUP-9813) Performance walkaround for ModuleTool::Tar::Mini, plus a perf test #7602
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
(PUP-9813) Performance walkaround for ModuleTool::Tar::Mini, plus a perf test #7602
Conversation
Can one of the admins verify this patch? |
Adding a pending performance test that clearly shows that ModuleTool::Tar::Mini is about 100x times slower then system `tar xzvf` command. Test should be unskipped if performance of ModuleTool::Tar::Mini is fixed. As a walkaround I'm switching to ModuleTool::Tar::Gnu implementation as default.
CLA signed by all contributors. |
Thanks for your contribution @cardil! We currently default to minitar to prevent problems like https://tickets.puppetlabs.com/browse/PUP-7390 and https://tickets.puppetlabs.com/browse/PUP-3198. I thought I read somewhere that the ruby minitar implementation performs |
Using minitar:
Using patched minitar to avoid fsync calls:
I don't think we can directly compare the above times to executing the
If we include
Given that I'm inclined to fix minitar, as in the maintenance costs with having different tar implementations (gnu/bsd/ustar/pax) outweighs the 2.3x performance benefit. |
@joshcooper I think Roby native implementation should be default as it is, but only when it performs well. Unfortunately now it performs awful. Switching to Gnu implementation on compatible platforms (Linux, Macos) should be a temporary solution. I can rewrite the code to default Minitar on other platforms (Windows, Solaris, HP-UX). Minitar performance should be boosted as a final solution. |
I've actually written in PUP-9813 that "t might be at most 2x times slower then system command" so I think your fixed minitar implementation achieve that goal 🍻 |
@joshcooper I've written a test in this PR that isolate extraction with minitar and compares it to tar system command. I'm wondering how your patched minitar performs in that test. Could you execute that test? |
Thanks for submitting this @cardil. I'm going to close this as we need to update puppet to call the new minitar method that allows us to skip fsync'ing every file and directory. See https://tickets.puppetlabs.com/browse/PUP-10013. We'll be sure to compare that performance with similar native tar. Hopefully minitar should be less than 2x slower than native tar. |
Installing modules from Puppet Forge is extremely slow. It's due to extraction of tarballs using
Puppet::ModuleTool::Tar::Mini
implementation. The unpacking is 100x times slower then executing atar xzvf
system command!As a walkaround I'm switching to
Puppet::ModuleTool::Tar::Gnu
implementation as default.Also, adding a pending performance test, that clearly shows that
Puppet::ModuleTool::Tar::Mini
is about 100x times slower then systemtar xzvf
command. Test should be unskipped if performance ofPuppet::ModuleTool::Tar::Mini
is fixed somehow.Issue: https://tickets.puppetlabs.com/browse/PUP-9813