Yak Private Custom Package is slow

Rhino Developer Yak
, , , ,
1

Hi!

We have our own file server inside our company where we push our internal plugins. Everything seems to be working correctly.

But when we are searching plugins with package manager or trying to find plugin depencies to scripts, its seems to be very slow compared to global yak server.

I mean, global server has way more plugings compared to ours. Searching tools from our server with package manager takes almoust half a minute. Our file server is Microsoft Azure File Share which is mounted to user computer and response time to that file share normally is pretty fast. But with Rhino its seems to be pretty slow.

Is there something that speeds things with searching packages? Maybe I am missing something essential? Is there something I can do?

1 Like
2

Is there any possible solution for this?

3

Hi Jaakko -

Not at this point, no. We have this on the list as RH-67625 (not public) and attempts have been made to find out why this is slow but no solution was found so far. I’ve added this thread to the issue report.

On my end, it takes about 6 minutes…
-wim

4

Thank you for reply.

5

have you considered caching file share to local server? e.g. using Azure File Sync.

1 Like
6

Hei, is there any update on that thread?

7

We are still hoping for a solution to this. We cannot really use a custom package repository because it breaks the package manager speed so slowly, that it’s unusable.

According to Rhino documentation at Rhino - Custom Package Repositories, they use Directory.EnumerateFiles() to list file share contents. This is a highly compatible, older way to do it that allows it to work with SMB network shares.

c# - Azure file Storage SMB slow to list files in directory - Stack Overflow points out that the modern, fast way to list directory contents with Azure Storage accounts will be to go through the REST API instead of making a ton of older SMB calls.

If I understood correctly, this requires the vendor (I am looking at you Yak) to add support for cloud-specific REST calls- in our case, for Azure Storage Accounts.

We tried to double increase the sharing/loading speed at our end (storage account), but that did not really help at all. Azure File Sync could be one solution, but it’s a little more complicated and expensive solution.

8

Any news on this @wim or @will ?

This is really problematic and hopefully will be resolved as soon as possible.

9

Hi -
I’m told that the speed will depend on the number of packages that are available on the server. This is not only the number of different packages that are published, but also all previous versions of a given plug-in that are still available. The only solution for the time being is to try to limit this total number of packages.
-wim

10

This is the correct solution for this issue. Essentially moving your files back local to your network. There are solutions for this whether you are using AWS or Azure.

Azure - FileSync:

AWS - Storage Gateway:

File Shares across the internet are always going to be slow and cause you issues…