【译】游戏性能的状态报告doc.docVIP

【译】游戏性能的状态报告 CHRIS LUNDQUIST 翻译出处：/2015/12/02/the-state-of-game-performance-reporting/ 原文作者未做权利声明，视为共享知识产权进入公共领域，自动获得授权 许多人使用过我们的游戏性能报告服务来获取崩溃报告，并对我们计划的跟进产生了?疑问。我和我的团队已经阅读了大家所有的帖子，进而我们知晓了大家都期待很酷的新功能！ 所以，带着需求和想法来吧！我们已经花费过去的几个月改造了从支持一个项目到支持一个超酷的、多层次的用来处理所有数以万计的Unity游戏的web应用程序的基础设施。继续阅读以了解更多我们所做的吧。 背景 Unity 游戏性能起源于一年前作为一个Unity黑客周的项目，仅仅是为了尝试新事物。 我们当中有来自不同背景的人付出努力，并且每个人负责一部分的崩溃服务，包括有： Javascript的界面 界面所使用的导轨接口 崩溃报告摄取通道 用户界面的变化可能是最明显的。你可能已经注意到平台已经推出，其目的是统一访问我们越来越多的服务。 对于这三块的崩溃服务，在过去的 它是如何工作的呢 本来, 摄入管道应该是像这样的： 编辑器插件 - 节点 - SQS + DynamoDB - 导轨 - MySQL 编辑器插件监听了异常，对它们批处理，然后把它们发送到节点。节点监听了事件，把它们放入DynamoDB ，然后它以 当时SQS 已经扩容? 当我们实际操作时发生了什么呢我们在GDC ‘15期间推出我们的黑客小项目，并且我们进行得比我们想象中要活跃。我们预期的是每天有数以千计的异常——实际上我们做到了数以百万计。我们不得不限制某些每秒发送以千计异常的项目速率。 除了运行问题以外，我们注意到我们的设置有一个很大的瓶颈。事件（异常）放入 对于原设置的一个乐观的事情是，接受事件和读取事件的方法是解耦的。这种设计可以在我们更新代码的同时，轻松启动或终止处理，而不会丢失任何事件。 我们接下来做的 抽象地说，处理一个崩溃报告包括以下步骤： 跟踪它的轨迹, 通过轨迹找到或创建, 增加计数器, 将它与我们所看到它的操作系统、平台相关联。 当然，仅对于快捷方面，我打算的是用我没学过的（）来替换我不喜欢（节点）。我尝试这么做，但也明白它不能再做的更好了，因为 我的目标是这样写的： 编辑器插件 - Go - MySQL 我想要的是简单和快捷。我不想看到因冗长的记录日志或滥用的 我最初的实现是来自一个导轨的直译。它仍然是执行 我的第一个优化是删除了所有报告之间被复制的语句。这些重复的语句是SELECT 语句，如‘SELECT id FROM operating_systems where name “Windows 7”’。这些语句是完全安全的应用缓存，并且我很大程度的利用了?Hashicorp’s go LRU hash来处理它。然后我执行了相同的最优化缓存崩溃痕迹，目的是我不必在我每次看到同样的异常时都要去访问数据库。 我不得不在这些每个?细粒度锁? 我遇到的下一个瓶颈大概要这么说：每写一个事件我都要去增加计数器。我的数据库保守数量在100,000,000。一次一个。 我知道我想要批处理我所写的，但我想用一个可靠的方法。我又再次拿起了Hashicorp的 LRU 散列，它提供了一个?上逐出钩。这样，当崩溃报告从我的内存被驱逐出时，它就会被写入数据库。但转念一想，”如果我没有得到足够的特定崩溃报告来触发一个驱逐呢？”所以，我去掉了它并添加另一个方法让你可以以存活时间来添加一个条目。 重要注意，存活时间存在于每个条目。这样一来，每个存活时间的逐出是交错的，使之不产生?异常成群?的数据库写入。 鉴于所有上述考虑，一个 t2.medium 实例可以（突发）约0请求每秒，这是相当不错的作用。 我们还计划在不同地区拥有边缘服务器。你的游戏将在最近的地理区域给服务器发送报告。这些服务会做同样的批处理，然后它们会将事件转发到数据库所在的区域。它们会使用相同的逐出钩来生成一个 TL;DR:, 我知道这里没有太多关于游戏性能报告的新闻，但我们从未忘记它。我希望这篇文章能帮助你理解我们一直在幕后所付出的。在我们的论坛与我们保持交流哦！