unity监视面板_监视Unity性能，第二部分

unity监视面板

This is the second part of my post about how we monitor Unity performance. In Part I, I explained how we monitor for and fix performance regressions. In Part II I’ll go into some details about how we do the monitoring.

这是我关于如何监视Unity性能的文章的第二部分。 在第一部分中 ，我解释了我们如何监视和修复性能下降。 在第二部分中，我将详细介绍如何进行监视。

Building the rig

搭建钻机

We have built a performance test rig that can monitor selected development and release branches and report selected data points to a database.

我们已经建立了一个性能测试平台，可以监视选定的开发并发布分支，并将选定的数据点报告给数据库。

The performance test rig is continuously running and looking for new builds to test from our build automation system. As soon as new builds are ready, it runs tests on all platforms we have setup for performance testing. The results get reported into a database with all the related information like Unity version used, platform and information about the hardware and operating system. We also have a reporting solution that continuously monitors the data in the database and shows us if we have a significant performance regression. It can tell us in which release branch the regression occurs, which platforms and tests are affected by it.

性能测试平台一直在运行，正在从我们的构建自动化系统中寻找要测试的新构建。 新版本准备就绪后，它将在我们为性能测试而设置的所有平台上运行测试。 结果将报告给数据库，其中包含所有相关信息，例如使用的Unity版本，平台以及有关硬件和操作系统的信息。 我们还有一个报告解决方案，可以连续监视数据库中的数据并向我们显示是否存在重大的性能下降。 它可以告诉我们回归发生在哪个发布分支，哪个平台和测试受其影响。

The figure below shows the components of the performance test framework. For running the tests we have dedicated machines running tests on different platforms. We use a .Net web service to report test results to the database. And we have a reporting solution that presents results in nicely formatted reports.

下图显示了性能测试框架的组件。 为了运行测试，我们有专用的机器在不同的平台上运行测试。 我们使用.Net Web服务将测试结果报告给数据库。 我们有一个报告解决方案，可以以格式正确的报告形式呈现结果。

When analyzing the test results we use a fixed set of hardware and software configurations and we look for changes over different versions of Unity. For example when testing Windows Standalone platform we use the same hardware and Windows version for all the runs. Only the Unity version is varying.

在分析测试结果时，我们使用一组固定的硬件和软件配置，并在Unity的不同版本中寻找更改。 例如，在测试Windows Standalone平台时，我们对所有运行使用相同的硬件和Windows版本。 仅Unity版本有所不同。

As all of the data is saved in the database, we can make reports from the data for different uses. For each Unity version we are about to release we make a chart that shows data points vs previously released versions. We can also see almost realtime status of performance tests for release branches we are developing in parallel. When analyzing a regression we can even see the individual measurements, not only the mean value.

由于所有数据都保存在数据库中，因此我们可以根据数据制作报告以用于不同用途。 对于我们将要发布的每个Unity版本，我们都会制作一张图表，显示数据点与以前发布的版本。 我们还可以看到并行开发的发布分支的性能测试的实时状态。 在分析回归时，我们甚至可以看到各个测量值，而不仅仅是平均值。

Currently we have three dedicated performance test machines for handling the test running. We have one Mac Mini (OSX 10.8.5) that is used to run tests on the Mac platforms (Editor, Standalone). We have two Windows machines (Windows 7, Windows 8.0) that are used to run tests on the Windows platforms (Editor, Standalone). And we have a Nexus 10 device to run tests on Android. We intend to extend this to more platforms, hardware and software configurations, but more on that later. And before you ask, yes, OSX 10.9 Mavericks is coming. We just didn’t get to it yet.

当前，我们有三台专用的性能测试机来处理测试运行。 我们有一个Mac Mini(OSX 10.8.5)，用于在Mac平台(编辑器，独立)上运行测试。 我们有两台Windows计算机(Windows 7，Windows 8.0)，用于在Windows平台(编辑器，独立)上运行测试。 我们还有一个Nexus 10设备，可以在Android上运行测试。 我们打算将其扩展到更多平台，硬件和软件配置，但稍后再介绍。 在您问之前，是的，OSX 10.9 Mavericks即将到来。 我们只是还没有实现。

Extending existing framework

扩展现有框架

We wrote about one of our test frameworks, the Runtime Test Framework, in an earlier blog post. For performance testing we have extended our existing test frameworks instead of creating a new one. This means we can tap into the existing test suites and use them for performance testing. Further, everyone that can write tests using existing frameworks can write performance tests. This also means it is easy to get new platforms running performance tests as soon as we have the platform running other tests.

我们在较早的博客文章中介绍了我们的测试框架之一，即Runtime Test Framework。 对于性能测试，我们扩展了现有的测试框架，而不是创建一个新的框架。 这意味着我们可以利用现有的测试套件并将其用于性能测试。 此外，可以使用现有框架编写测试的每个人都可以编写性能测试。 这也意味着，只要我们让平台运行其他测试，就可以轻松让新平台运行性能测试。

The test suites

测试套件

We have split the tests into two types called Editor Tests and Runtime Tests based on how they get run and what can be measured. Editor Tests are limited to the platforms the editor runs on. Editor Tests can make measurements outside of Unity user scripts. The tests measure things like editor start-up time and asset import times for different types of assets. Runtime Tests, on the other hand, can be run on all the supported runtime platforms. With Runtime Tests it is possible to measure things like frame time of rendered frames or to measure the time it takes to deserialize different types of assets. It is actually possible to measure anything you can do with user scripts in Unity.

根据测试的运行方式和可测量的内容，我们将测试分为两种类型，称为编辑器测试和运行时测试。 编辑器测试仅限于运行编辑器的平台。 编辑器测试可以在Unity用户脚本之外进行测量。 这些测试测量的是诸如不同类型资产的编辑器启动时间和资产导入时间之类的信息。 另一方面，运行时测试可以在所有受支持的运行时平台上运行。 使用运行时测试，可以测量诸如渲染帧的帧时间之类的东西，也可以测量反序列化不同类型资产所需的时间。 实际上，可以测量您可以在Unity中使用用户脚本执行的所有操作。

The future

未来

First of all we will add more configurations. Hardware and software. OSX 10.9 is high on the list, and so are the remaining mobile platforms and consoles. We truly believe that the performance rig is a lifesaver when it comes to detecting performance regressions as early as possible. Further, the rig makes it very easy to compare performance across different platforms and versions of Unity. We will keep you posted as we find interesting results – and different usages of the rig.

首先，我们将添加更多配置。 硬件和软件。 OSX 10.9排名第一，其余的移动平台和控制台也是如此。 我们坚信，在尽可能早地检测性能下降时，性能装备是救生员。 此外，该平台使在不同平台和Unity版本之间比较性能变得非常容易。 我们会在发现有趣的结果以及钻机的不同用法时通知您。

翻译自: https://blogs.unity3d.com/2014/01/08/monitoring-unity-performance-part-ii/

unity监视面板