Cache Server makes creating with Unity faster by optimizing the asset-import processes either on your local machine or a dedicated server for teams working in a local area network. Version 6.0 of the remote Cache Server is now available and is a culmination of a six-month work on improving the quality and performance of the Cache Server. In fact, the improvement is so big that we decided a blog post is in order. Download Remote Cache Server now on GitHub, and read on to learn more.
When using the Unity Editor, every time an asset is added or modified in a project, an import process is triggered. As your Unity team gets larger, this creates two issues. First, there will be more assets in the project, and second, the assets will change more frequently.
Ultimately, you and your teammates lose valuable development time while the editor calculates and imports project changes. The problem is further compounded for multiplatform projects. When switching target platforms, all platform-dependant assets in the project (e.g. textures, audio) go through the conversion process again, which can take hours for large projects.
To speed up this process, the Asset Cache Server can be deployed on a local system for individual use, or in a LAN/WAN environment for teams collaborating on one or more projects. The Unity Editor uses the Asset Cache Server to store and retrieve multiple platform asset representations while amortizing the cost of asset imports across your entire team.
In the recent past, we heard from many developers who were experiencing poor performance, such as hanging in the Editor, and other problems when using the Cache Server. It was becoming apparent that the Cache Server architecture was strained beyond its original design, and needed some focused attention to bring it up to speed with the current Unity architecture and quality standards.
In the rest of this blog post, I'll recap our journey through the process of benchmarking performance, identifying bottlenecks, and making target fixes to deliver improvements to our developers as quickly as possible.
Because we don't have a large team working on a big game inside of Unity, we had to simulate a real-world scenario to help us quickly identify performance problems that only manifest at large scale. Our test environment consisted of:
We tested the Cache Server running both for a single Unity Editor connected to a Cache Server running on the same system, and as a hosted server on a gigabit ethernet LAN.
For the hosted server, we tested the following scenarios:
The results of our tests were immediately telling. The single Unity Editor client connecting to a local server showed no discernable problems, with good overall performance. The two-client case on LAN also performed well. Things started going bad with the WiFi-connected clients and became almost unusable in the large-scale synthetic test. Server lock-ups, client disconnects, and other failure scenarios manifested quickly and frequently. We needed to discover where the bottlenecks were.
The Cache Server is a Node.JS server application, which has been proven to be a very scalable platform for I/O centric applications — certainly well beyond the dozen concurrent clients that we tested here. So what could be the problem?
A few obvious things jumped out:
Before committing to any major course of action, we hypothesized on a handful of optimization strategies. We then did some quick implementations to measure their impact.
The results and observations of these tests were as follows:
Based on our experimentation, we decided on a two-phase course of action. For phase 1, we would target the low-hanging fruit and get the code in shape for future improvements.
Version 5.4 of the Cache Server was released last September with these changes, only two weeks after our initial performance investigation. Additionally, the bug fixes uncovered in this process were backported to the Cache Server distributed with the Unity Editor, back to version 2017.2.
Since version 5.4 has been released, we've received a lot of positive feedback from developers who were previously experiencing problems with the Cache Server.
Since the release of v5.4, we've been rebuilding the Cache Server from the ground up to lay a better foundation for maintainability and future enhancements. We also wanted to provide a high-end solution for the most demanding enterprise environments that currently deploy and maintain their own custom-build Cache Server solution.
Version 6.0 brings improved reliability and performance, as well as a host of new features, including:
Is this article helpful for you?
Thank you for your feedback!