缓存服务器Cache Server 6.0发布

89 阅读 0 评论 59 点赞

我是靠谱客的博主要减肥龙猫，最近开发中收集的这篇文章主要介绍缓存服务器Cache Server 6.0发布，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

无论是在个人的本地电脑，还是在团队的局域网专有服务器上，缓存服务器都能通过优化资源导入过程让使用Unity开发的速度变得更快。远程缓存服务器Cache Server 6.0版本现已发布，缓存服务器的质量和性能获得大幅提高。

这次的改进十分庞大，下面将由Asset Bundles研发主管Stephen Palmer为大家介绍详情。

访问GitHub下载Cache Server 6.0：
https://github.com/Unity-Technologies/unity-cache-server

缓存服务器解决了哪些问题？
在使用Unity编辑器时，每次增加或修改项目中的资源时，都必须进行一次导入过程。当参与Unity的开发团队逐渐壮大时，这样会产生二个问题：

项目中会有更多资源。
资源会更频繁地被修改。

由于Unity编辑器需要不断计算并导入项目变更，你和团队成员会浪费大量宝贵的开发时间。对于多平台的项目而言，这个问题还会更为复杂。因为在切换目标平台时，所有项目中依赖平台的资源，例如纹理、音频都会重新进行转换，这个过程在大型项目中甚至会耗费多达几个小时。

为了加快这个过程的完成速度，资源缓存服务器可以部署在本地系统供个人使用，也可以部署在局域网或广域网环境下，方便团队合作完成项目。Unity编辑器会使用资源缓存服务来储存和恢复多个平台的资源形式，同时分摊整个团队中的资源导入成本。

缓存服务器的目标
我们从不少开发者处得知，在使用缓存服务器时，他们遇到了诸如性能低下等问题。很明显，缓存服务器的架构已受制于其最初的设计，需要进行特别处理使其能符合当前Unity架构和质量标准。

在本文中，将讲述我们通过性能检测、障碍识别和目标修复来为我们的开发人员尽快提供改进结果。

性能测试

因为Unity内部没有专门创作游戏的大型团队，我们不得不模拟真实世界的场景，从而快速识别仅在大型项目才遇到的性能问题。

我们的测试环境包括：

一个用Python编写的综合测试客户端，用于模拟超大流量，它的PUT/GET大小和并发连接数都是可配置的。
在多个Mac OS和Windows下测试Unity编辑器，使用Python客户端和Unity编辑器客户端来模拟载入过程。
一系列演示项目，特别是《Adam》内部和外部环境项目以及在我们支持库中的大型客户项目。

我们对连接缓存服务器的单个Unity编辑器进行了测试，服务器和编辑器运行在同一系统上，也在千兆以太局域网上将缓存服务器作为托管服务器运行并测试。

在托管服务器上，我们测试了以下几种情况：

二个通过以太网连接的Unity编辑器客户端。
二个通过Wi-Fi连接的Unity编辑器客户端。
由Python综合脚本客户端和Unity编辑器客户端组成的大量客户端（不少于12个客户端）。

性能测试结果
测试的结果十分明显。连接到本地服务器的单个Unity编辑器客户端没有发现问题，总体性能不错。在广域网上连接的二个客户端也表现得很好。

问题就发生在使用Wi-Fi连接的客户端，它们在大型综合测试时几乎无法使用。服务器查询、客户端断开连接等一些失败情况会更为频繁而快速地出现。我们需要弄清楚这些问题产生的原因。

代码测试结果
缓存服务器是一个Node.JS服务器应用，它对于I/O为中心的应用来说是个具有高度可扩展性的平台，它比我们在这所测试的多个并发客户端要好。所以问题出现在哪呢？

比较明显的几个问题：

代码缺乏自动测试套件。没有测试组件的话，要想在安全地对其更改以便进行性能改进测试，这几乎是不可能的事。而且，还有一些隐藏错误导致了一些已发现的问题。
大量I/O同步文件调用。首先Node.JS是单线程的。其次，虽然Node.JS的文件系统支持同步和异步方式，我们原来主要采用的是同步操作。因此，调用或是进行CPU密集型任务会很快降低整个服务器的性能。
在整个缓存大小超过限制时，服务器释放空间的方法十分消耗资源，并且会触发对整个目录的遍历，使所有新文件都被写入缓存中。
管理协议处理和文件系统缓存的代码互相交织，使得在对特定目标进行优化时，很难隔离其它系统。

性能改进实验
在对特定问题进行处理前，我们对一些优化策略进行了预估。然后做了一些快速实现来评估它们所产生的影响。

更新优化：我们制作了一个快速方法，用来尽可能多地移除同步调用，然后改进了一些库的用法。
集群：我们实现了Node.js的集群，它将服务器分成可配置数量的离散进程。
缓冲：我们试着通过缓冲套接字的写入来消除从服务器上传客户端时的套接字延迟。
“缓存到缓存”：我们实现了一个内存缓存，里面包含小型的（大小可配置，但目标小于64KB）缓存对象，从而减小了文件系统I/O。

这些测试的结果和观测如下：

更新优化和集群：在大量测试负载下，测试结果显示了更高的稳定性。它不会崩溃或是冻结，也没有与连接超时的服务器断开连接。
缓冲：这个方法的结果比较复杂。综合测试表现出了一定的改善效果，但是实际的客户端测试则不一定。在Cache Server 6.0中，我们充分利用了Node.JS流架构来确保客户端和服务器之间的数据流尽可能高效。
“缓存到缓存”：这项优化在综合测试中效果拔群，但在实际的客户端测试中略有逊色。这种差异是因为一些综合测试使用了小型的标准资源，这类资源很适合这项优化策略。而实际客户端则更多地会有一些未排序资源大小，所以造成了二个结果的差异。

第一阶段更新 : Cache Server 5.4
基于这些实验，我们决定分二个阶段进行改进。在第一阶段，我们会先处理比较简单的问题，并对代码进行修改以方便以后的改进。

为了提高错误修复的部署速度、使其拥有更快的发布周期和直接的社区贡献，我们将这部分开发移至GitHub上，代码在Apache 2.0协议下开源。
我们实施了一套完整的测试套件，它能测试出一些重要的错误。
增加了Node.JS集群支持，所有文件I/O操作都会与主要工作部分相隔离。在高负载情况下，这会大幅提升稳定性和性能。
为了方便进行维护，我们重构了代码，将代码中的协议和文件系统功能分离开。

在最初的性能调查完成后，仅过了2周，缓存服务器Cache Server 5.4便于去年九月发布。而且，在此过程中发现的错误修复会被回退到Unity 2017.2时发布的缓存服务器版本。自从Cache Server 5.4版发布后，我们收到了大量来自开发者的积极反馈，他们在此之前都遇到了缓存服务器的问题。

第二阶段更新 :Cache Server 6.0
自从Cache Server 5.4发布以来，我们一直在从头开始重建缓存服务器，为了可维护性和未来改进打下更好的基础。我们还希望对最为苛刻的企业环境提供高端解决方案，这些企业环境当前正部署和维护他们自行定制的缓存服务器解决方案。

Cache Server 6.0有更高的可靠性和性能，还有一些新功能，包括：