As of now I do not know how to find which parts of the app are inefficient compared to others without normalizing the results to make up for traffic/usage. Which would be time consuming and difficult to determine for every area of my app.
@josh @emmanuel, when we get an improved chart to lookup WU consumption can we also have metrics of which areas of the app are the least efficient at consuming WUs?
ie workflows/searches WUs based on per initialization / per page load / # of times run
Right now when I lookup what is using WUs it is an absolute number which usually is just showing me which parts of the app are most used - not necessarily that they are inefficient. While this metric is useful I also need to track down inefficiencies which this does not show.
As an example, I have a page that I know gets a lot of traffic/usage and it understandably is using more WUs than other areas of my app.
But if I have another page in my app that that all of a sudden gets a a large amount of traffic, then it will only appear on these chart metrics after the fact when it’s total WUs is large enough (after I have paid for all of the WUs). And then it will be time consuming for me to figure out if the page is inefficient or if it was simply a large number of users that caused it to run so many WUs.
It seems unreasonable to have to go through testing every area of my app one by one as a single users and manually track these numbers so I can extrapolate it out for my userbase. And then do this again every time I adjust the workflows and searches to recalculate things and determine if it’s an affordable change.
A way to quickly see this ‘heavy usage per load’ within the Metrics tab would be ideal so I can quickly estimate how much ‘heavy’ pages/features will cost ahead of time to prepare for high traffic situations - which feels crazy to have to do this for every feature but I guess it will be the new normal.