Poor first-time install/usage experience as cacheserver replacement - macOS

Unity Engine
1

hey Unity,

just testing a project upgrade from 2019.2 to 2019.3 and Asset pipeline v2 on macOS (Mojave). I wanted to test the replacement of the existing one-click easy-to-use just-works cacheserver on my primary working machine with a cacheserver that works with Asset pipeline v2. So far I’ve spent an hour installing, uninstalling, reinstalling, and not being able to configure or use the Accelerator (Unity-Accelerator-v1.0.288).

Unity-Accelerator-v1.0.288+gf7a97d0, installed on same machine as Unity
macOS 10.14.6
ssd, 200+gig free space
No apparent log errors (apart from warnings about the OS not having enough file handles)
Dashboard works but cannot edit any settings
Unity 2019.3.10f1 working normally with Asset pipeline v2, connects ok to Accelerator (according to the editor)
Unity 2019.2.17 working normally with built-in cache server

My first-time experience of installing and using Accelerator has been pretty poor - it does not work at all. The editor gives no indication that a separate install is required for a cacheserver. There’s a note in the docs on the cacheserver page but not in the editor settings page for the cacheserver that Accelerator is required. At first glance the Accelerator docs are quite complex for non-technical devs and I expect most of our team (currently distributed) will not be able to understand how to install and configure the service as a simple 1:1 replacement for the old local cacheserver without assistance.

The installer is fairly verbose (ok fair enough) and installs a daemon that can be controlled via terminal commands. By default it also starts the www monitor dashboard on port 80 (clashing with other services) and also configures itself to use down to the last 5% or (on my machine) 1.1gig of free space. I have tried to update these settings using the dashboard configuration but all I see is an endless spinner and the dashboard does not respond again. After restarting the service no changes take effect.

I appreciate that services like Accelerator are useful and aim to make life easier in the end but so far without further manual work editing config files and launch daemon stuff nothing works out of the box. I realise that it’s probably still under a fair amount of development but the editor and docs show ‘deprecated’ everywhere for the old tech, so I would expect the new stuff to be a fair replacement.

Do you have any plans to emulate the ease of use of the original built-in local cache server for those devs who are less technical? Are you aware of any current installation and service configuration problems on macOS?

cheers,

// greg

ps. the current macOS docs list the launchctl service as “com.unity.accelerator” but it’s appearing in the launchctl list as “com.unity3d.accelerator”.

2

Thanks for the excellent feedback, @greg-harding ! We are already working toward many of the items you’ve raised and will be opening up some new tickets for anything that wasn’t already in progress.

Regarding the request “to emulate the ease of use of the original built-in local cache server”, I’m curious as to reasoning around this option. I’ve heard this from other customers and it’s nearly always coming from the expected need for a local caching solution. However, the new version of the Asset Import Pipeline already has this built-in!

A primary driver for the new pipeline was to include a database for artifact caching without any need to host a separate process to manage the artifacts. To that end when you upgrade to 2019.3 or later and enable support for the V2 database, it will host your cached artifacts in your Library folder. This alleviates a lot of pain around local build target switching or branch switching by utilizing the cached results locally. The Accelerator will only improve on this local cache when working with changes received from other team members.

3

hey @bradunity , thanks very much for your reply. I’m happy to help with any repro if you need it.

Thanks for the info on the Asset pipeline v2 having built-in caching! I think my question about reproducing the original cache server is because I obviously have not read anywhere that the new Asset pipeline v2 does this and is an out-of-the-box replacement for the old tech.

If the current docs mention it then apologies for missing it, but I didn’t see it in the editor settings docs or the cache server docs explicitly, and several searches of the forums turned up questions similar to mine during the alpha and beta, with replies from Unity saying yes the docs were due for attention. I think this reflects a more general problem with the docs being out of date in places. Useful and important information is fairly scattered - docs, forums, answers, blog posts, github repos, etc. which is fine but the docs are often not authoritative. (Argh, the editor api docs.)

Also, performance of the new Asset pipeline v2 in my quick tests vs the old pipeline with local cache didn’t really suggest caching was happening - platform changes were veeery slow. Once again, I appreciate this is new tech and the old stuff has only just been deprecated. The forums have performance results all over the place, some reports of it being quite fast, other reports of it being slower. No doubt it will improve.

The Accelerator should be useful for our team when we are back working on the same network, so I will continue to test it when new versions come out - hopefully some of the issues I mentioned above are ironed out soon. Thanks again for your reply - much appreciated.

1 Like