Hey,
Retrieving actions is horribly slow, is there anyway to speed this up?
edit: in the web ui*
we are running a shared config and a shotgun desktop from a shared location,
so the commands should always be the same.
maybe its scanning for software on the local machine,
if so can i control, cache or feed this my own list somehow?
Hey sorry for the troubles, but thanks for reaching out here.
We are aware there are some scenarios where the actions can take a while build and we have been looking at ways we can speed it up. That said there maybe somethings you can do to improve the performance here. I have a few questions:
I think it’s probably unlikely that the software scanning is slowing it down, that’s usually pretty fast. The software scanning will not happen if you provide a path for the software on the Software entity itself.
Best
Phil
Shotgun is currently caching to the local hard drive, i have not looked into stopping it.
is this a do or don’t? would love to have it server side if its not a massive slow down.
We currently only have two custom actions nuke/maya, however we have not removed the standard on this example its:
we are using a site wide config with a path descriptor set as per the guide that was uploaded here recently.
Local test:
Should be possible but since we had to get the tools up and running quickly i have not explored
other ways of setting up configs, are you talking about isntalling SG desktop locally or an entire project with config and all locally?
Thanks for that. Your setup sounds reasonable.
The cache is better of being kept locally from a performance perspective.
You can move the bundle_cache portion of the cache by setting the env var: SHOTGUN_BUNDLE_CACHE_PATH env var. You can also move the whole cache with SHOTGUN_HOME but I would advise against moving it to a server as the access to the SQLite dbs we store in there dramatically slows down, and the caches contain user-specific data.
As for being installed locally, it would be interesting to see SG Desktop installed locally and the project’s config stored locally as well. Just to understand if the slow down is directly related to the storage access speed.b n
Thanks
Phil
Okey we will keep cache locally for now,
if we can resolve this performance issue we might try it server side, mostly to humor me.
Thanks for adding the “how to” if i decide to try it.
There are two separate slow downs one they encounter dailie and one the first time they launch
sg desktop.
Every time you launch sg dektop and then log into the web ui the actions take 1-5min to load,
only showing the “Retrieve Actions” action after some time and then the full list after another delay, this is slow enough that users start updating the page in frustration.(not helping)
Then its fast for most of the day until the user either restarts browser, computer or what seems to be an time limit.(haven’t looked into how long).
the later is after SG has been launched first time, since our user switch computers this happens more often than it sounds like,
After the first launch the actions don’t load at all, it just stops on “Retrieve Action” and refuses to load until the hole system has been rebooted, does not matter if you relaunch SG desktop or the browser that holds the web ui.
Our actions are software run without SG engines with a fixed file path and a single argument set in the software tab in shotgun,
the argument is then picked up in app_launch.py and from there branches to our own hook that builds the env and launches the software.
How would i go about disabling all the standard actions so i am only left with the ones set in the software tab?
so jump to screening, publish, show in file system, etc…
Hmm yeah that doesn’t sound good. Are you changing the config regularly, is it possible that the recaching corresponds to changes in the config. That said changes shouldn’t affect it anyway as the changes should be recached in the background and the old cached results should be displayed until the cache has been updated.
Removing the actions I think is unlikely to have much impact, but I can certainly show you how to.
The tk-shotgun engine, is the engine that is used to run the actions from the browser. You can configure what apps are available in the tk-shotgun engine by modifying this file (in your config):
There are different setting blocks depending on the context. The tk-multi-launchapp: "@settings.tk-multi-launchapp" line covers all Software entity entries, so make sure you leave that in there and disable any Software entities that you don’t want via your site. Some software like Mari, Hiero and Motionbuilder are not handled by the Software entities approach so you can just remove them from the list of apps.
It would be great to get a log from you so that we can look down an example of the slow loading or it not loading them at all. I wouldn’t recommend attaching it publically in this topic, so you can either message me directly here or put a support request in for that. If you could enable debug logging reproduce the issue and then send the tk-shotgun.log and the tk-desktop.log that would be awesome.
Also just a thought, but make sure debug logging isn’t enabled for your users (during normal use), as this will slow things down as well.
Seems to work better now,
setting SHOTGUN_BUNDLE_CACHE_PATH seemed to do the trick.
also removed unused actions in the config and a few other adjustments, but that ENV seemed to do most of it.
It was updating the app_store folder in the bundle cache a lot.
thanks for your help.
OK, I’m glad it’s working better for you, though I’m not sure I could explain why setting the env var would help here unless you were moving it to a faster storage location.
Is it possible your user folders were actually kept on a network location?
No i watched them update, on the local drive in the user folder.
win: C:\Users\ >USERNAME< \AppData\Roaming\Shotgun\bundle_cache\app_store\
what seemed to happen was that it updated it every time you restarted the machine,
and that check/update was slow enough to be annoying.
The first time you ran SG dektop it pulls the hole thing down per user, not sure if it does this from your server or the SG install on our server?
now that its on the network it does not update it it just reads it.
we don’t update the apps in the bundle caches app store folder,
but we are actively working on the pipeline config not sure if changes there prompts it to update the bundle cache?
Setting the SHOTGUN_BUNDLE_CACHE_PATH env var will mean that once one user has populated the central bundle cache with all the required apps, engines, and frameworks for the config, all further users won’t need to download it. So there is an initial gain for all other users who then don’t have to download the dependencies themselves. However, there is a potential cost in time else whereas the files now need to be loaded off the server instead of a local drive.
Setting the environment variable won’t stop the check, however. Essentially it checks that the dependencies in the config are present in the bundle cache (where ever it is) and will download them from our app store if they are not.
So I can see that it would be faster for users the very first time they start SG Desktop on a given machine, however after that including restarts it shouldn’t be downloading anything again unless the config has changed to point at different versions of the dependencies.
Basically the env var sets a custom path for the bundle cache, but doesn’t alter the behaviour.
It should still update it, but only if there is a change to the config to point to a different version of a dependency that can’t already be found in the bundle cache. But this is the same whether you set the env var or not.
That said I’m not disputing the performance increase you’ve seen, but I’m still not sure why you would be getting slow loading after restarting a machine.