I would like my workshop app to load much faster. Using the Workshop Profiler, I see that my Properties widget takes the longest to populate. Screenshot attached. My properties widget does traverse linked objects for some of the property values to show, so I assume that’s what is slow.
Any suggestions?
My thinking:
- Make a copy of the linked properties in my core object (Ticket), so that the property widget only loads properties on my core object vs. having to traverse objects and get their properites. The downside is that I will have to update all my functions to make sure the “Status Name” on my Ticket object is always correct, while the linked Status object is the real source of truth.
- Is there anyway to load the page and have those trickle in later? So like load all the properties that aren’t linked and then load the linked ones?
In addition, we have some functions that run calculations on our ticket, for SLAs. That function seems to take a while. Could we have that load after the page loads too? It would be on-screen, but like have that load last or something. Alternatively, I could have an automate that run every minute to update the SLA values for all tickets, but that seems expensive.
1 Like
Hi @cedarchase
Unless you are not doing big linked object set aggregations of millions of linked values, loading a few linked properties (like a status, type, priority) shouldn’t be too heavy imo 
- Make a copy of the linked properties in my core object (Ticket), so that the property widget only loads properties on my core object vs. having to traverse objects and get their properites. The downside is that I will have to update all my functions to make sure the “Status Name” on my Ticket object is always correct, while the linked Status object is the real source of truth.
That would be a really unfortunate resolution, since it defeats the main purpose of the ontology no?
But you could test your assumption, can you maybe narrow down the properties of suspect by dropping them one by one and check the loading times?
Maybe there is one black sheep that takes for whatever reason long.
My other assumption would have been that you are having a function-backed property that could just be coded not performantly. But from your screenshots it’s not looking like that.
One point that confuses me is, why is the property list 1 loaded twice? One taking 2.77s the other 8.8s
1 Like
Below are some more tests. I think the issue that any linked object property is slow. Also, I agree, saving the property on the core Ticket would defeat the whole point of the ontology, but we deal with so many tickets I would rather this load faster. That is more important for this use case.
It wasn’t loading the same property list 1 twice, there are just 2 widgets in the workshop app with the same name. So ignore that.
To fix this loading speed, is there something Foundry product could do? Like index common linked search arounds? Every ticket view load, its the same search around. There aren’t many objects either.
Reloaded it 3 times with all 4 linked object properties
2.73 seconds
3.56 seconds
3.17 seconds
I removed only the Component linked object property
2.47 seconds
2.82 seconds
I removed only the Issue Type linked object property
3.37 seconds
3.17 seconds
I removed only the Priority linked object property
2.49 seconds
2.71 seconds
I removed only the Project linked object property
2.75 seconds
3.74 seconds
I removed all the linked object properties. This is why I’m really considering exploring this option. Its so much faster for the properties directly on the object.
0.44 seconds
0.23 seconds
0.27 seconds
