New post
0

Any toolkit speed up tricks?

Avatar
Michał Krupa
None
Follow

Hi.

I'm a bit fresh with shotgun and shotgun toolkit but there is one thing that bothers me: the speed of starting the softwares with shotgun.

It takes like 19 seconds from pressing the "Launch Nuke 7.0" menu item until the nuke splashscreen shows up and exactly 30 seconds until nuke stops to initialize and is ready to work.

Starting nuke simply from the start menu takes 3 seconds.

 

Now - how can we make the software running faster? We have the toolkit installed on the very fast network drive and I have the firefox shotgun plugin installed. Is there something I've messed up or that kind of delay is normal?

 

Date Votes

11 comments

  • 0
    Avatar
    KP

    Hey Michał,

    Thanks for reaching out. While Toolkit does need to run a few calls to initialize when launching Nuke, that does seem quite slow. Could you answer a few questions for us so that we can narrow down the issue?

    1. What OS are you seeing this on? 
    2. Is the delay the same on other OS-es (if you are running multiple different OS-es).
    3. Is your internet connection pretty reliable at your location in general? With Shotgun?

    If you launch Nuke from the command-line using the snippet below  (replace the Shot id below with one from your setup though), you should be able to see where in the launch process things are getting hung up. Can you try it and then reply with the results?

    $ cd /path/to/my/sgtk/project
    $ tank Shot 1229 launch_nuke --debug

     

    cheers,
    kp

  • 0
    Avatar
    Benoit Leveau

    Sorry to (temporarily) hijack this thread, just wanted to say that it's the first time I see a mention of the "--debug" option. To my knowledge, it's not mentioned anywhere in the documentation or on the command line help. Would be worth adding it somewhere...

    Benoit

  • 0
    Avatar
    Permanently deleted user

    Sorry about that Benoit and thanks for bringing it to our attention!

    I have added a section to the docs about the debug mode: https://support.shotgunsoftware.com/entries/95442818

     

  • 0
    Avatar
    KP

    [including part of this discussion that happened offline]

     

    The slowdown happens every time I'm re-launching the Nuke.

    I wonder if I've messed up something with the config of the directories or maybe it's something wrong with our network file system.

    Michael

    ---

    Thanks for the info. We're looking at it and will discuss this morning. One thing I'm curious about is if it takes the same amount of time to get to the splash screen if you re-launch Nuke from the same task again. I can see the bulk of that time is spent creating folders on the filesystem and it shouldn't have to do that more than once really. The post-splash-screen delay would be potentially from the Nuke engine and apps so we can move on there after we dig in here a little bit.

    kp

    ---

    Hi! I've attatched the log from console. I was running nuke for a Comp task. However this log stops at the moment when the nuke splashscreen shows up. From that moment it takes another 10 - 15s for the nuke to start.

    I'm using Windows 7 x64 and as far as I know it's a little bit faster on linux but I've had no chance to test it myself.

    We have a really good uplink (my speed tests shows about 600Mbps for download and 500Mbps upload) so I don't think that it's a connection issue.

    I've noticed that import of the sgtk module in python takes more than 3 seconds.

    cheers 
    Michal Krupa

  • 0
    Avatar
    KP

    Have you customized the folder creation stuff at all? That may help pinpoint some of the issue. Especially if you're using additional Shotgun fields in the schema, this can generate a lot of queries to the server while it's creating or validating the folder structure for that context.

    The fact that there is a continued delay after the splash screen is displayed seems to hint at the app loading steps being slow. Unfortunately we've noticed that especially when Toolkit is installed on networked drive on Windows, this can be quite slow. One way to figure out if this is indeed the case is to try doing a local install.

    1. Clone the PipelineConfiguration for your Project and map it to a local drive on your machine. 
    2. Localize the core API 

    docs for this can be found on our site here: https://support.shotgunsoftware.com/entries/95441337

    Then try launching Nuke using the cloned PipelineConfiguration with the local files. If it starts up quickly, then we've at least identified the issue. Let us know what you find.

    We're working on some ideas for making this issue better. Network installs are convenient in giving everyone access to the files but they're not always the speediest. And as I mentioned, Windows especially can be particularly slow in this regard. We're doing some work to try and help improve this issue though. We hope to have more to share in the near future. 

    In the meantime, let us know how the localized test goes and if you're doing anything particularly custom for your schema in your folder creation.

  • 0
    Avatar
    Michał Krupa

    Ok - I've found that our server where we've been keeping all the cache files is quite slow. After moving the configuration to C: the nuke startup time dropped to 15s. 

     

    Is it possible for every user to keep a copy of path cache on his local drive?

  • 0
    Avatar
    KP

    Well finding the culprit is a good first step! Unfortunately right now we don't support having a local cache for each user but we're actually investigating that at the moment, along with some other ideas. I've added you to our internal ticket for that so we can be sure to follow up with any updates. 

    I'll talk to the team to see if there's anything else we can suggest right now. 

     

  • 0
    Avatar
    Michał Krupa

    Ok - after few days of testing I've found the cause but not the solution.

    In my setup I have a linux file server and a multiple of windows workstations. It seems that Windows 7 Professional does not work too well with samba.

    Because of that, whenever I access the samba share from linux it works ultra fast, but the same share works slow under Win 7.

    However when I'm sharing a directory from Win 7 and accessing it from Win 7 it works fast...

     

  • 0
    Avatar
    KP

    I think the main issue here is that Samba shares from Windows 7 are generally slow to begin with (you can confirm this with a quick Google search). There is theoretically a way to tune these so they're more efficient but after talking to the team this morning, none of us have ever seen this tuning actually work.

    Our suggestion would be to try and avoid this situation if possible. One option we'd recommend is to try NFS. Is that an option for you? 

  • 0
    Avatar
    Michał Krupa

    Unfortunately we use Windows 7 Professional on our workstations and the NFS support is only for the Windows 7 Ultimate. As far as I know there is no well tested stable NFS driver for windows.

  • 0
    Avatar
    KP

    Crud. Yeah you're correct of course! Not sure if you saw this already: http://www.trevorpott.com/nfs-client-in-windows-7-pro/. There's some discussion on Studiosysadmins about this too: http://www.studiosysadmins.com/board/threadview/4515/. There someone also says that NFS was still pretty slow so maybe this isn't a viable option still.

    Admittedly, this is a little out of my expertise. You might want to try posting a thread on studiosysadmins about this and see if anyone on there has suggestions for tuning your Samba share or other options. 

Please sign in to leave a comment.