我们的许多客户将他们的整个工作日都花在对讲机上，在收件箱、用户列表和用户配置文件页面之间切换。我们的目标是用一个漂亮快速的产品取悦这些人，小程序建站，而不是用缓慢的页面呈现或web浏览器内存泄漏来挫败他们。在不同的时期，我们已经对对讲机的性能进行了显著的改进，但我们并没有始终达到我们自己设定的确保性能始终保持优异的标准。这篇博文是一系列定期业绩报告中的第一篇。我们将分享原始的绩效数据，强调积极和消极的变化，并讨论将对绩效产生影响的未来项目。我们从Etsy这样的大公司那里得到了灵感，这些公司以前就解决过这些问题。定期分享绩效细节将：为我们的客户提供性能数据的可视性请允许我们庆祝性能改进当业绩恶化时，让我们保持诚实最近的性能改进第一次装载：我们之前说过要把对讲机的前端移到余烬，以及如何让我们为客户提供更丰富、更愉悦的体验。当客户加载对讲机时，他们浏览器加载的第一个页面是一个简单的html页面，用于引导Ember应用程序。为了加快引导过程，返利怎么用，我们开始在这个页面中嵌入一些JSON。但是随着时间的推移，越来越多的数据被嵌入，这实际上导致了性能的下降。我们看到平均响应时间约为700毫秒。7月份，我们发布了一些优化方案，将中值降至约350毫秒：

这是一个很好的结果，但是p99（这个端点所有请求中最慢的1%）仍然慢得令人无法接受，几乎只有3秒。上周，我们改进了这些最坏情况下的请求，现在大约需要一秒钟：

用户列表：我们的客户在加载对讲机时看到的第一页是用户列表。它可以让他们看到谁是他们的客户，他们在做什么。用户列表是对讲机的第一部分余烬. 当我们切换时，大数据分析技术，它感觉比以前的版本快得多。然而，ecs云服务器，我们没有任何客户端工具，随着我们添加新功能（增加复杂性），性能显著下降。当我们开始记录客户端性能指标时，我们发现简单呈现一个包含30个用户的页面的平均时间为1500毫秒。当我们意识到我们让客户体验如此严重地恶化时，真是令人沮丧。在7月份，我们大大简化了用户列表中每一行的呈现过程，并将呈现页面的中值时间从1500毫秒减少到600毫秒。我们对我们的进展感到满意，但仍然不够快。

收件箱：大量使用对讲机的用户往往会花很多时间在收件箱里。今年我们增加了许多新功能（实时聊天、工具提示、悬停卡、动画），这些都对性能产生了负面影响。长时间的谈话（有数百条评论）受到的影响尤其严重。我们最近花了大量时间研究收件箱性能，并取得了显著的效果。我们是这样做的：已开始分页对话。呈现整个会话历史记录意味着，随着会话变得更长（常见于实时消息传递），呈现会话所需的时间呈线性增加。分页对话意味着我们一次只能渲染25个部分，这将导致呈现时间更短、更一致，以及更好的客户体验。避免不必要的工作。以前每次有人回复时，我们都会重新呈现整个对话历史记录。现在我们只呈现最新的评论，这使得事情变得更加简单。非常显著地简化了客户端渲染，在不删除任何功能的情况下，将单个注释组件的呈现时间减半。实现了会话的客户端缓存，这大大加快了会话之间的切换。大量的服务器端控制器改进。以下是对返回已保存回复的控制器的影响示例：

可能的未来项目通过最小化昂贵的数据库调用，进一步提高启动Ember应用程序的页面上的最坏情况（p99）性能。通过进一步减少服务器和客户端延迟，大数据数据处理，继续改善用户列表上的客户体验。结合使用令人震惊的和定期的绩效指标评估，以确保我们不会在最近的任何绩效改进上掉以轻心。我们打算不断降低性能，直到我们获得了我们引以为豪的体验。目标：快得令人高兴将对讲机前端移动到余烬使我们能够为客户提供更丰富的体验。它还提供了snappier性能，因为状态更改往往是不需要重新呈现整个页面的小操作。我们未能充分测试客户端应用程序意味着，随着我们添加更多功能，以前的快速操作开始滞后，在某些情况下，我们的性能比以前更差。我们现在收集、监控和执行客户端指标，虽然我们对当前的性能数据还远远不满意，但我们在上个季度取得了显著的改进。我们决心为我们的客户提供快捷的对讲机，并期待着与您分享下一份业绩报告。