Thank you Willkg for your thoughts. > We should build a list of things to keep an eye on so we know if removing the cache degraded something more than we would like. For Eliot, we could monitor the existing [SYM download timings panel](https://earthangel-b40313e5.influxcloud.net/d/IwaI3KISk/eliot-app-metrics?orgId=1&refresh=1m&viewPanel=55) in the Eliot App Metrics dashboard. For the last 90 days, I estimate the mean download timing to be around 250ms. However, IIUC Eliot can make use of other sources for downloading SYM files than Tecken, and I don't see that this metric can currently be broken down by source. Is there another way to determine what percentage of downloads Eliot makes using Tecken as the source? Else should this dimension be added to this existing metric? For the Socorro processor, I'm less certain that there's an existing metric we could watch, though from reading the [processor docs](https://socorro.readthedocs.io/en/latest/service/processor.html#stackwalker) (and looking at the code/stackwalker's code), the stackwalker does cache fully downloaded SYM files. I saw that there's a [Stackwalker timings panel](https://earthangel-b40313e5.influxcloud.net/d/LysVjx8Zk/socorro-prod-app-metrics?orgId=1&refresh=1m&viewPanel=101) in the Socorro Prod App Metrics dashboard, though I imagine those timings measure the symbolication process in its entirety and it would be difficult to suss out the component related to downloading a SYM file. > My gut feeling is that Socorro processor throughput won't change much because (if I recall correctly) the stackwalker parallelizes symbol file downloads. Eliot symbolication API might be a different story. I can leave this ticket open for a month or two after merging the patch to monitor Eliot as described above (similar to [Sven's approach](https://bugzilla.mozilla.org/show_bug.cgi?id=1865415#c8) for Bug 1865415). Would that be acceptable?
Bug 1759554 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Thank you Willkg for your thoughts. > We should build a list of things to keep an eye on so we know if removing the cache degraded something more than we would like. For Eliot, we could monitor the existing [SYM download timings panel](https://earthangel-b40313e5.influxcloud.net/d/IwaI3KISk/eliot-app-metrics?orgId=1&refresh=1m&viewPanel=55) in the Eliot App Metrics dashboard. For the last 90 days, I estimate the mean download timing to be around 250ms. However, IIUC Eliot can make use of other sources for downloading SYM files than Tecken, and I don't see that this metric can currently be broken down by source. Is there another way to determine what percentage of downloads Eliot makes using Tecken as the source? Else should this dimension be added to this existing metric? For the Socorro processor, I'm less certain that there's an existing metric we could watch, though from reading the [processor docs](https://socorro.readthedocs.io/en/latest/service/processor.html#stackwalker) (and looking at the code/stackwalker's code), the stackwalker does cache fully downloaded SYM files. I saw that there's a [Stackwalker timings panel](https://earthangel-b40313e5.influxcloud.net/d/LysVjx8Zk/socorro-prod-app-metrics?orgId=1&refresh=1m&viewPanel=101) in the Socorro Prod App Metrics dashboard, though I imagine those timings measure the symbolication process in its entirety and it would be difficult to suss out the component related to downloading a SYM file. > My gut feeling is that Socorro processor throughput won't change much because (if I recall correctly) the stackwalker parallelizes symbol file downloads. Eliot symbolication API might be a different story. I can leave this ticket open for a month or two after deploying the patch in prod to monitor Eliot as described above (similar to [Sven's approach](https://bugzilla.mozilla.org/show_bug.cgi?id=1865415#c8) for Bug 1865415). Would that be acceptable?
Thank you Willkg for your thoughts. FYI, I added some references to my previous comment to help explain what I'm basing the data/estimates from. > We should build a list of things to keep an eye on so we know if removing the cache degraded something more than we would like. For Eliot, we could monitor the existing [SYM download timings panel](https://earthangel-b40313e5.influxcloud.net/d/IwaI3KISk/eliot-app-metrics?orgId=1&refresh=1m&viewPanel=55) in the Eliot App Metrics dashboard. For the last 90 days, I estimate the mean download timing to be around 250ms. However, IIUC Eliot can make use of other sources for downloading SYM files than Tecken, and I don't see that this metric can currently be broken down by source. Is there another way to determine what percentage of downloads Eliot makes using Tecken as the source? Else should this dimension be added to this existing metric? For the Socorro processor, I'm less certain that there's an existing metric we could watch, though from reading the [processor docs](https://socorro.readthedocs.io/en/latest/service/processor.html#stackwalker) (and looking at the code/stackwalker's code), the stackwalker does cache fully downloaded SYM files. I saw that there's a [Stackwalker timings panel](https://earthangel-b40313e5.influxcloud.net/d/LysVjx8Zk/socorro-prod-app-metrics?orgId=1&refresh=1m&viewPanel=101) in the Socorro Prod App Metrics dashboard, though I imagine those timings measure the symbolication process in its entirety and it would be difficult to suss out the component related to downloading a SYM file. > My gut feeling is that Socorro processor throughput won't change much because (if I recall correctly) the stackwalker parallelizes symbol file downloads. Eliot symbolication API might be a different story. I can leave this ticket open for a month or two after deploying the patch in prod to monitor Eliot as described above (similar to [Sven's approach](https://bugzilla.mozilla.org/show_bug.cgi?id=1865415#c8) for Bug 1865415). Would that be acceptable?
Thank you Willkg for your thoughts. FYI, I added some references to my previous comment to help explain what I'm basing the data/estimates from. > We should build a list of things to keep an eye on so we know if removing the cache degraded something more than we would like. For Eliot, we could monitor the existing [SYM download timings panel](https://earthangel-b40313e5.influxcloud.net/d/IwaI3KISk/eliot-app-metrics?orgId=1&refresh=1m&viewPanel=55) in the Eliot App Metrics dashboard. For the last 90 days, I estimate the mean download timing to be around 250ms. However, IIUC Eliot can make use of other sources for downloading SYM files than Tecken, and I don't see that this metric can currently be broken down by source. Is there another way to determine symbols download timings using Tecken as the source? Else should this dimension be added to this existing metric? For the Socorro processor, I'm less certain that there's an existing metric we could watch, though from reading the [processor docs](https://socorro.readthedocs.io/en/latest/service/processor.html#stackwalker) (and looking at the code/stackwalker's code), the stackwalker does cache fully downloaded SYM files. I saw that there's a [Stackwalker timings panel](https://earthangel-b40313e5.influxcloud.net/d/LysVjx8Zk/socorro-prod-app-metrics?orgId=1&refresh=1m&viewPanel=101) in the Socorro Prod App Metrics dashboard, though I imagine those timings measure the symbolication process in its entirety and it would be difficult to suss out the component related to downloading a SYM file. > My gut feeling is that Socorro processor throughput won't change much because (if I recall correctly) the stackwalker parallelizes symbol file downloads. Eliot symbolication API might be a different story. I can leave this ticket open for a month or two after deploying the patch in prod to monitor Eliot as described above (similar to [Sven's approach](https://bugzilla.mozilla.org/show_bug.cgi?id=1865415#c8) for Bug 1865415). Would that be acceptable?
Thank you Willkg for your thoughts. FYI, I added some references to my [previous comment](https://bugzilla.mozilla.org/show_bug.cgi?id=1759554#c3) to help explain what I'm basing the data/estimates from. > We should build a list of things to keep an eye on so we know if removing the cache degraded something more than we would like. For Eliot, we could monitor the existing [SYM download timings panel](https://earthangel-b40313e5.influxcloud.net/d/IwaI3KISk/eliot-app-metrics?orgId=1&refresh=1m&viewPanel=55) in the Eliot App Metrics dashboard. For the last 90 days, I estimate the mean download timing to be around 250ms. However, IIUC Eliot can make use of other sources for downloading SYM files than Tecken, and I don't see that this metric can currently be broken down by source. Is there another way to determine symbols download timings using Tecken as the source? Else should this dimension be added to this existing metric? For the Socorro processor, I'm less certain that there's an existing metric we could watch, though from reading the [processor docs](https://socorro.readthedocs.io/en/latest/service/processor.html#stackwalker) (and looking at the code/stackwalker's code), the stackwalker does cache fully downloaded SYM files. I saw that there's a [Stackwalker timings panel](https://earthangel-b40313e5.influxcloud.net/d/LysVjx8Zk/socorro-prod-app-metrics?orgId=1&refresh=1m&viewPanel=101) in the Socorro Prod App Metrics dashboard, though I imagine those timings measure the symbolication process in its entirety and it would be difficult to suss out the component related to downloading a SYM file. > My gut feeling is that Socorro processor throughput won't change much because (if I recall correctly) the stackwalker parallelizes symbol file downloads. Eliot symbolication API might be a different story. I can leave this ticket open for a month or two after deploying the patch in prod to monitor Eliot as described above (similar to [Sven's approach](https://bugzilla.mozilla.org/show_bug.cgi?id=1865415#c8) for Bug 1865415). Would that be acceptable?