This message was deleted.
# community-supports
Slackbot
10/20/2022, 3:59 AMThis message was deleted.
c
Chris Lee
10/20/2022, 4:33 AMDepending on the system configuration (available memory, CPUs) and size of project it wouldn’t be unusual for a Gradle build to consume CPU & memory, resulting in other resource exhaustion that affects other apps. Monitoring CPU and memory usage will help quantify this.
m
Mike Cumings
10/20/2022, 4:20 PMYou might also have some success attempting to use
org.gradle.priority=lowe
Esa Firman
10/21/2022, 4:37 AMMonitoring CPU and memory usage will help quantify this.We already did this, in fact, we have 2 months data of it. Now we need a formula for the metric that will tell us if a user have seamless experience when they executing a build or not.
Esa Firman
10/21/2022, 4:38 AMYou might also have some success attempting to useYes, this is one of many things that we can do to improve the experience. But how can we measure it?as documented here.org.gradle.priority=low
m
Mike Cumings
10/21/2022, 5:48 PMThe answer to that would necessarily be OS specific. One critical metric would be your build durations. i.e., you down-prioritize system resources the build will get longer. That can be easily measured with Gradle Enterprise build scans. If you're looking at system-level metrics you could investigate how to measure process/task scheduling latency to measure CPU delays. There are similar tools for I/O delivery latency as well.
Mike Cumings
10/21/2022, 5:49 PMnetdata is a pretty useful tool for gathering and rendering pretty much every meaningful system metric under the sun. There are other similar tools as well.
e
Esa Firman
10/22/2022, 12:47 AMThanks for the answer Mike, but as I mention in the original post, we already gather the data and all (minus the I/O data).
The problem is, how we can translate or use that data to determine if the user have a slow IDE performance.
One of my test, using multiple process of
yes > /dev/null