-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Stop caching COPY layers #1408
Stop caching COPY layers #1408
Conversation
061250f
to
41db1cc
Compare
Sorry, couldn't get all of the tests to run on my macbook so I decided to "test in CI". Clearly not working. The tests run as expected on a Linux box, will fix them there. |
41db1cc
to
e25cf1d
Compare
Cached COPY layers are expensive in that they both need to be retrieved over the network and occupy space in the layer cache. They are unnecessary in that we already have all resources needed to execute the COPY locally, and doing so is a trivial file-system operation. This is in contrast to RUN layers, which can do arbitrary and unbounded work. The end result is that cached COPY commands were more expensive when cached, not less. Remove them. Resolves GoogleContainerTools#1357
e25cf1d
to
71f1d34
Compare
Unit tests are good to go now, I removed some obsolete test cases and added a new one. I think that integration test that failed is flakey? It was not failing previously. |
@isker If a file in the copy command changes, then the Run command will be invalidated since the composite key for the previous COPY layer will be different.
The cache key for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
code change looks good.
Pending Manual Verification
Hi @tejal29, anything else you need me to do here? |
Verified this is working on my build. |
Sorry for the delay @isker |
No worries. Thank you!
…On Wed, Sep 30, 2020 at 8:19 PM Tejal Desai ***@***.***> wrote:
Merged #1408 <#1408>
into master.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1408 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABH3ZNKEPTL5XX6GBUFULQTSIPDHRANCNFSM4QQ7O5RA>
.
|
@isker did you end up testing v1.2.0? |
@tejal29 have not had time yet to do so but I will let you know the results when I do. |
sounds good. no one has reported issues yet! |
@tejal29 with Kaniko 1.2.0, we're seeing the improvements we expect. Before, it took the same amount of time to build our image with caching on as with it off, because we were stuck downloading and uploading large COPY layers, with the added cost of maintaining the layer cache with caching on. Afterward, we see a 30-40% improvement in build time with caching on, and of course our layer cache is smaller. Thanks for your support on getting this merged and released! |
Thanks @isker |
Resolves #1357
Description
Cached COPY layers are expensive in that they both need to be retrieved over the network and occupy space in the layer cache.
They are unnecessary in that we already have all resources needed to execute the COPY locally, and doing so is a trivial file-system operation. This is in contrast to RUN layers, which can do arbitrary and unbounded work.
The end result is that cached COPY commands were more expensive when cached, not less. Remove them.
Submitter Checklist
Reviewer Notes
Release Notes
COPY
commands in its layer cache as the associated network and storage costs outweigh the costs of executing them locally.