This message was deleted.
# community-supports
Slackbot
09/21/2023, 8:08 AMThis message was deleted.
v
Vampire
09/21/2023, 8:46 AMHighly depends on who writes to the cache and how often it runs cacheable tasks with different inputs. I'd just start with any value your DevOps is happy with without proof of need and just see how it works out and increase it if you see it is not enough
➕ 1
j
Júlio Cesar Bueno
09/21/2023, 8:49 AMbut how to measure what is enough ?
v
Vampire
09/21/2023, 8:50 AMCheck used space?
j
Júlio Cesar Bueno
09/21/2023, 8:51 AMin less than one day we reach the 10GB limit...
v
Vampire
09/21/2023, 8:52 AMWell, isn't that enough proof for your DevOps then? :-)
j
Júlio Cesar Bueno
09/21/2023, 8:54 AMDon't know, the cache may be filling, but are those artefacts being used ? Maybe they are being kept, but not used...
v
Vampire
09/21/2023, 11:59 AMLook at access numbers?
They are used if someone with remote cache enabled tries to execute the same cacheable task with the same inputs and then gets the cached result.
Vampire
09/21/2023, 11:59 AMIf noone does that, the entry of course is not used.
r
Roldan Galan
09/21/2023, 12:23 PMYou can check the hit rate over the last 24 hours, last week and last 3 months in the Build cache usage section (if you are using Gradle Enterprise remote cache node). If your hit rate is low it will be another good reason to proof you need to increase it.
Also in that page you can see the Data Received during those periods (which is how much data you are trying to store), so it could be a good indicator. Of course if you have lower space than required, you will be evicting and storing more than the actual values that you should need. But can be a good hint if you need to show some data to your DevOps.
Roldan Galan
09/21/2023, 12:42 PMI am going to show you some real data from our projects that can help you with this estimation, because something similar happened to us last year.
We noticed this 10gb default limit in the node and increased to 100gb. We monitored the build node and 24 hours later the cache got full and started evicting.
Some weeks after the increase we compared the numbers:
• Data sent over past 24 hours, from 35 gb to 110 gb (these are cache hits!)
• Data received over past 24 hours, changed from 43 gb to 19gb. (cache misses that require to be stored)
• Data received last 7 days, changed from 540 gb to 83gb.
• Hit ratio passed from 82% to 96% for last 24hrs
• Hit ratio passed from 90% to 97% for last 7 days.
I don’t have the precise numbers on the impact of this action in the build time, as we were taking also other measures during that period of time, but during the following weeks we got 25% faster PR builds in the CI and I am quite confident that this was the most meaningful action taken in that period.
j
Júlio Cesar Bueno
09/21/2023, 3:37 PMis this a paid feature of remote build cache?
r
Roldan Galan
09/22/2023, 7:47 AMIf you are using Gradle Enterprise remote build cache, these stats are available in the Build Cache configuration page (
yourGEdomain/cache-admin/usagethank you 1
j
Júlio Cesar Bueno
09/22/2023, 8:57 AMwe have an image of build-cache-node... I tried to access
cache-admin/usage4 Views