Thanks, I didn’t know conditionals cost more WU. I’ll consider that, though I was hoping for a more concrete answer on working on it and being able to optimize.
I do have things related to things among some of the repeating groups, I’m not sure what can be best practice to structure this though and if that could be it.
For example, we have a Bag, that has a list of Events, that each can hold a list of Tickets.
I’m not sure the best way to do this though, if it is the issue. Would it be best to, instead of storing a list of Event things inside a Bag, storing a list of numbers/texts to store the unique IDs of the events they’re related to? I considered this, as we need to show them as related information (like, this Event comes from Bag A or Bag Z… or this is a Ticket from Event 1 from Bag 2). But then we’d have to Search Events by curren’t cell’s Bag’s Event filtered by the Bag’s Event text ID and not sure how much better that is than just storing it and referencing it (this bag’s Events vs. Search for Events whose bag_uniqueID is this bag’s unique ID). We might also have a profile page showing an Event’s Tickets in a repeating group.
Sometimes we also have conditionals on repeating groups to apply filters by the user’s preference or query, like say the user wants to see pink Bags only so the conditional will change the source of the repeating group like “if this custom state filter is pink, Search Bag’s filtered etc…”, “if custom state filter is green, Search Bags filtered by name green…”. But these aren’t used too often, so condition is mostly false. I also have conditions like Make changes only when… Current Ticket is not empty/a condition checks yes (which I do precisely to avoid WU for making changes when not applicable or sometimes for functionality). Make changes only when it’s been more than 7 days, etc…
/// An idea I had to avoid the constant referencing of Things of Things would be to store the first Ticket’s Title in a single Event text field (as, Event ticket_title) and entirely remove the list of Tickets from the Event, especially since we only need to show the first Ticket’s title to browsing users. So, avoiding lists stored anywhere at all costs. This would mean though that we’d also have to set an Event data field to each individual ticket, so when we show a particular Bag’s Event’s Tickets instead of doing this Bag’s Events:item #x’s Tickets: first item we’d just do for Search for Tickets, filtered by Event matches clicked Event. But that also means we’d have to elsewhere source the tickets differently, so instead of referencing Event’s Tickets we’d have to add a new Search for Tickets:filtered id matches this Event’s unique ID.
There’s lots ideas I’ve had and some things I have tried, unfortunately this is a lot of experimenting and I’m trying to make it feel less like a shot in the dark. To just try the idea above we’d have to re-structure a lot of our setup, risk many bugs (after finally stabilizing features), and we’d also have to make changes to thousands of things in our database which will thousands of WU long term (to update existing user creations) and who knows if it’s not that much better and we end up having to reverse it which is not great. Otherwise I’ll also recreate test pages with sections of the app… but what if it’s workflows? Or how the data is structured in the database? I have to somehow test this and I don’t know how without having to make such disruptive and uncertain changes. It’s certainly easier when you can click and pinpoint specific workflows or searches that are weighing things down unnecessarily out of inefficiency.
Not sure if this any of this may actually be it though. There’s also conditionals on elements across the app (such as, This Ticket is not clickable when current user is not Event’s creator/border color turns blue/not visible/etc. changes), which looks like might be part of it but who knows? There are so many angles. It’s a mystery… Currently this is what I’m looking at from just starting up the page itself… Trying to get them down because at this rate this cycle we might be paying overages again for sure (before considering upgrading our tier, 1-10 users shouldn’t rack up 1k WU per day at any point and we can’t scale that way). We can’t afford to pay hundreds for hardly 500 users.
Photos for reference:
Currently this is what I’m looking at from just starting up the page itself… App has a lot of work put into it, it is single-page and mobile friendly, has about 1,200 workflows, and some many dozens of groups. Hopefully I can figure something out for the sake of everything.
(In Search section largest search consumes1.4 WU maximum. Most WU coming from individual data requests, trying to test) Result of a single-person page load:
Below, a day we had spike in workload units less than a week ago. We had maybe 9 users that day according to google analytics, most just browsing information. Also had changes done to database by 1-2 users but those were not most of the WU as seen in top hour:
January 9 we had a huge spike too where we reportedly had 17 users or so (mostly reading for under 2 min), something caused a lot of WU and it wasn’t database changes. We removed a bad recurring workflow, which improved things slightly (on the right), but we’re still left with the individual data requests which is most of everything, same as first image.
If anyone has tips please help.. Many things I’ve been able to optimize as much as reasonably can, but this one I’m truly lost on. Will keep testing…
