115. Demystifying the User Experience with Performance Monitoring
26:23 Share

您好，欢迎收听Kodish，一个探索现代开发者生活的节目。加入我们，一起深入探讨编程语言和框架、数据和事件驱动架构以及个人和团队效率等主题，所有内容都专为开发者和工程领导者量身定制。本期节目是我们“工具与技巧”系列的一部分。

欢迎收听Kodish。我是Greg Noakes，Salesforce Heroku的杰出技术架构师。今天我和Raygun的高级开发者Innocent一起探讨问题。Innocent，你能简单介绍一下Raygun是什么以及你在Raygun的工作吗？

Raygun专注于性能监控领域。我们提供开发者用来改进软件质量的工具和实用程序，包括崩溃报告以及浏览器和应用程序性能监控。那么，您是如何处理性能监控和应用程序自省的呢？所以，

当我看到一个性能欠佳的应用程序时，首先，我的理念是：没有崩溃报告并不意味着软件运行良好。软件中隐藏着一些问题。我们在开发时使用的工具并非都能像我们希望的那样完美运行。

我的意思是，它们确实完成了工作，但其中有些方面可以改进。所以我倾向于从整体的角度来看待问题。我会查看我的受众规模。如果这是一个相当大的群体，并且流量很大，例如在黑色星期五期间流量很大的购物车。

我希望在高峰期我的应用程序仍然能够正常运行，这样我才能安心。所以我倾向于关注最终用户，查看他们在高峰期时的体验。从那里，我开始追溯到支持该应用程序的技术。

因此，首先要考虑的是用户的加载时间以及他们在终端体验到的响应代码。从那里，我尝试确定问题是出在他们的浏览器上还是服务器端的软件上。

如果问题出在服务器端的软件上，那么我将开始检查所有围绕该应用程序的应用程序，这些应用程序支持客户看到的最终产品。

并将其分解，找出我遇到的异常情况。如果没有异常，那么就检查幕后运行的查询。如果我使用的是对象关系映射器，这是我最喜欢的一种方法。

然后，我会查看某些代码路径的执行频率，以及我们是否遇到任何N+1查询，并研究重构代码的方法

并重新设计我们向用户呈现的数据，以便它能够以更一致和及时的速度从数据库中提取。我想在Raygun，你们提供了可以进行这种自省的工具，以便在运行环境中检查代码，然后获得关于它实际运行情况的良好反馈？是的，我们确实提供。

这是一个周全的方法，但并非所有情况都适用。有时，我发现自己不得不

在我的应用程序中添加一些任意的度量指标，这些指标会在Raygun不提供的单独仪表板中报告。但总的来说，Raygun确实为我想要在我的应用程序性能中引用的大多数内容提供了一站式服务。是的。我喜欢使用的一种策略是分解

单个请求，就像你说的那样，了解我在不同函数中花费的时间，与我的后端服务（无论是数据库、API还是其他服务）通信所花费的时间，并查看我可以在哪些方面进一步优化高命中率的端点或在我的代码中经常访问的端点的性能。Raygun也能帮我做到这一点吗？

我认为这是Raygun真正闪光的地方，因为它直接描绘了从用户体验到服务器端性能的画面。因此，当您在浏览器中加载页面时，性能遥测数据会发送到Raygun，以及在服务器端运行的应用程序性能应用程序监控以及由此产生的崩溃报告，

然后，我们可以将所有这些遥测数据关联起来，向您展示这种用户体验与这些崩溃报告相关联，并且与服务器端的这些堆栈跟踪相关联。因此，您可以全面了解浏览器上的客户体验与后端服务器性能之间的关系。

这听起来非常强大。那么，你们是否让用户将一些JavaScript代码注入到他们的网页和一些代码中以捕获执行情况？或者你们有其他方法来收集这些遥测数据？

是的，我们确实采用了这种方法，将一小段轻量级的代码注入到前端的JavaScript中。我们在后端有一个非常轻量级的SDK，可以连接到您的异常。

而APM则采用了一种不同的方法，您无需在代码中执行任何操作，但您必须安装一个针对运行代码的服务器运行的代理。所以我认为它就像一个轻量级的gem（因为我是一个Ruby开发者），我可以将其添加到我的bundle或文件中，然后安装。

传递一个API令牌来访问你们的服务器，以便我可以开始直接馈送这些信息，然后开始生成这些报告。

是的，这是完全正确的。既然您是Ruby开发者，我过去几周一直在APM团队工作，我们确实为Ruby推出了APM。哦，太棒了。它的工作方式是，您将引用一个或两个gem，具体取决于您使用的是Rails还是Sidekick。

这个gem，您随后提供一个环境变量，该变量在第一次运行时保存您的API密钥。一旦我们在第一次运行时看到该API密钥，它就会持久存储在一个JSON文件中，我们会一遍又一遍地读取它，只要您重新启动应用程序即可。现在，我看到您也有一些问题。

崩溃报告。您是否使用相同的工具进行崩溃报告？您是在自省日志还是使用什么工具？对于崩溃报告，我们有轻量级的SDK或轻量级的提供程序，您可以将其注入到您的代码中。通常情况下，有两种方法。

我们提供了一个通用的方法，因此所有未被优雅地终止请求的未处理异常，我们都可以捕获这些异常并对其进行报告。但还有一种更好的方法，因为我们尝试鼓励开发者在使用软件时遵循最佳实践。其中一个最佳实践是

您应该预测并处理应用程序中的所有异常，以便用户体验不会很糟糕。

而是优雅地处理并尝试在可能的情况下恢复。但是异常就是异常。当它发生时，您确实需要知道它。因此，我们确实提供了一种在异常发生时手动发送异常的方法，您可以在try-catch块中捕获它们。我不确定Ruby中的等效方法是什么。

我是.NET开发者。因此，我将从.NET的角度给出示例。因此，当您捕获异常时，实际上该异常已被处理，它可能不会一直冒泡到通用捕获钩子中。因此，您必须实现一些手动日志记录，并且

与我们将这些异常记录到文本文件然后查看它或记录到数据库的方式相同。您只需将这些异常记录到Raygun即可。这样做还有一个额外的好处，就是

您可以添加标签和额外信息，例如与遇到该异常的用户相关的信息。当您知道谁受到了影响、何时发生以及在哪里发生时，它会为您提供更好的故障排除选项。

因此，能够将浏览器体验和服务器端的代码自省结合起来，这似乎非常强大。您是否有跟踪用户在应用程序中旅程的方法？因此，我可以使用匿名数据，查看一个用户在应用程序中传输时的情况，并查看他们访问的所有端点，以及他们的个人体验如何？

是的，我们确实有。因此，我们的RAM工具在与您的应用程序集成时，首先，您的用户信息是可选的。因此，当您选择加入时，您可以使用您最感兴趣的信息填充字段。

因此，那里的匿名化部分完全由您控制。然后，我们使用内部会话ID跟踪用户。因此，与您的代码（前端的JavaScript）集成的SDK会创建一个会话ID，我们在Raygun内部跟踪该ID

并且我们跟踪用户访问的每个页面。该内部ID可以与您的崩溃报告相关联。例如，如果

您的用户遇到JavaScript异常，该异常也会通过Raygun发送到崩溃报告端点，并带有相同的会话ID。我们还会检查与浏览器发出的会话ID关联的会话ID。

当您在服务器端遇到异常时，该浏览器会话ID存在于该异常中。这就是我们能够关联这两者的方式。因此，我们实际上拥有完整的用户体验

以及他们在服务器端的个人会话。这真的很酷。是的，随着时间的推移，我们还能够全面了解用户会话的执行情况，从他们访问您的页面、登录、访问几个页面，然后离开您的应用程序开始。与该特定用户相关的崩溃报告和跟踪

也在Raygun端与该会话绑定在一起。但重要的一点是，对于APM，我们不会

跟踪每个用户的全部跟踪，这取决于您选择的采样比率，因为APM往往会发送大量数据，其中许多数据可能只是您不感兴趣的冗余信息。因此，我们有采样策略可以减少很多噪音，并在有有趣信息时提供一些有趣的信息。

因此，并非所有用户都可能有跟踪，但如果您将跟踪设置为一对一，我们将拥有所有这些信息。那么，您是如何将，您知道，我理解拥有可以跟踪用户的用户令牌，您是如何将多个用户的体验和多个应用程序的体验结合起来的呢？

函数体验到应用程序整体性能的整体视图中，几乎就像一个通用分数一样。你们有这样的概念吗？是的，我们确实有。我们一直在讨论用户详细信息，这是深入分析的结果。

当我们实际向上提升几个级别并获得应用程序的鸟瞰图时，您将获得应用程序性能的聚合统计数据，例如RAM产品。

无论您在一个时间段内有多少用户，您都会随着时间的推移对每个页面进行聚合。您不会查看单个会话。这些信息会被聚合，您可以看到，例如，您的中位数、P90和P99。

这正是我对RAM产品感兴趣的地方，因为我倾向于关注P99值。任何处于此值的用户都经历了糟糕的体验，这构成了我调查的基础。我想知道为什么P99中有这么多会话，而P99可能是一个6到7秒的加载时间。

我想将其缩短到3秒以内。因此，任何位于P99桶中的用户都让我感兴趣，我可以进一步深入到他们的特定会话中，找出发生了什么。通常情况下，您会发现我们可能在美国有一个数据中心，而这个客户则位于

例如南非，他们的加载时间受到延迟的影响，我们对此类用户无能为力。或者也许可以。AWS现在在南非也有数据中心。因此，这可能意味着我们需要将他们的流量路由到更靠近他们的数据中心，以消除这种延迟。

或者我们的资产加载速度慢得多。我们可能在他们附近有一个缓存站点。因此，我们确实有能力对所有内容进行鸟瞰，并确定我们真正想要深入研究的特定领域。

是的，我希望我们有一种方法可以打破光速。当我们谈论数据中心之间的延迟时，我总是和人们开玩笑说，我们还没有找到打破光速的方法，但我们正在努力。所以，请继续关注。也许有一天我们会做到。

我完全同意您关于P99的观点。在过去的12年中，这对我来说确实成为了一种圣杯，那就是我越能降低P99值并使其尽可能低，我的所有客户在我工作的任何网站上的体验就越好。因此，我认为很多人并没有考虑P99，因为当我与新的客户交谈时，他们

他们只是在进行性能优化的旅程，很多时候我必须教育他们什么是P99。所以也许我们可以花几秒钟的时间，您可以告诉我您对P99的理解。因此，任何不了解它的听众都将了解它是什么以及为什么它如此重要。

好的。我对P99数字的理解，以及我们如何将其显示给客户，它是一个聚合值，您的部分客户会落入其中。如果您要绘制正态分布曲线，它看起来像一个钟形

并且有一条长尾会向右延伸，几乎像渐近边界一样。在这条长尾的尖端，您有一个带有任意数字的桶。如果您网站或应用程序上有数百万客户，那么这个数字可能在数十万。

我一直将此与行为联系起来。我自己是千禧一代，千禧一代之后的年轻一代比我更有耐心，而我比我之前的婴儿潮一代更有耐心。所以我希望最大化利润，我知道我正在与那些没有耐心等待网站加载缓慢的人打交道。

我举个例子。如果我在网上购物，而我正在购物的应用程序性能不佳，我会直接关闭它并转到下一个。如果下一个也不好，我会关闭它并转到下一个。所以我对保留这些加载时间缓慢的用户很感兴趣。

因此，对我来说，P99代表了对应用程序体验最糟糕的人数。这就是为什么我对它特别感兴趣，并找出影响这少数人的原因。如果我能解决他们的问题，

我可能已经改善了之前98%的人的生活。没错，这正是我思考的方式。这是一个极好的解释。

因此，我们从浏览器和应用程序中收集了所有这些数据。我们已经将其整合到仪表板和总体指标中。除了降低P99值之外，您建议人们使用所有这些数据来做什么？您认为人们应该将收集到的关于应用程序性能的所有信息用于什么？

好的，根据我的经验，我了解到决策应该基于数据。我认为在我的职业生涯中，大部分时间我都忽略了很多数据，而没有真正根据经验来证明我们为什么做出某个决定。

如果我可以举一个这些数据确实帮助我做出许多决定的例子。在我之前的角色中，我是一个团队负责人，我们有一个在该公司存在超过两年的问题应用程序。问题是我们试图一次性完成所有事情。

然后连接一些监控工具并增强用户体验。然后我们意识到我们在一次调用中做了太多事情，并且某些事务显然可以被推迟并在后台处理，而无需用户等待反馈，因为大多数时候他们根本不关心这种反馈。

几乎立即。这将是他们可能一个月后需要查看的聚合报告或其他内容。我的意思是，查看这些数据使我能够重新设计应用程序，我采用了命令查询责任隔离模式

其中非关键任务的事务被后台的多个工作程序推迟处理。而关键任务的事务则以事务方式实时执行。因此，当您实际查看应用程序的性能时，您必须确定快乐路径是什么，关键路径是什么，

并决定将处理推迟到以后在后台进行。并非所有事情都需要是事务性的，也并非所有事情都需要是实时的。因此，我们正在收集所有这些指标

对其进行报告并为您提供需要查看的数据，以便做出明智的决策。如果您问我为什么应用程序最初的设计方式是所有内容都是事务性的，那是因为有人忽略了最佳实践，并忽略了该应用程序。

负载会很小，事情会运行良好。但随着时间的推移，事实证明这并不成立，它需要彻底重新设计。因此，您可能是一家正在经历这些应用程序持续问题的公司，您无法决定保留什么和放弃什么。

拥有此类数据使您能够看到关键路径是什么，客户的快乐路径应该是什么样子，并根据实际可操作的数据做出明智的决策。

您还有什么结束语吗？我认为开发人员的生活很有趣。我们在情况允许的情况下适应各种环境，并且我们确实会采取不同的途径来发展我们的职业生涯。但最终，我们都应该关注的是我生产的产品的质量，

这绝对反映了我作为软件开发人员的能力。让我与其他开发者区分开来的不是我能用代码完成的炫酷技巧的数量，而是交付一个真正有效的产品。当您实际测量事物时，还有什么比这更好的方法来了解什么有效呢？每个人都应该遵循这样的理念：不要假设任何事情，测量一切。

一切的一切都应该被测量。这是一个极好的建议。与您交谈真是太好了。这对我有教育意义，我了解了很多关于Raygun以及你们的工作以及你们如何看待性能自省的广阔空间。与您交谈真是太好了，Innocent。期待再次与您合作。就这样，

再次感谢您来到Kodish。感谢您的邀请。我喜欢这种关于技术和最佳实践的讨论。感谢Heroku和Salesforce推出这样的活动。

当然。我们总是很乐意回馈社会，并与业内人士交谈。就像我以前的一个老板曾经说过的那样，他不相信这个行业中没有几道伤疤的人。因此，能够展示我们的伤疤以及背后的故事，并希望让其他人获得与我们不同的伤疤。是的，这绝对是我们应该做的事情。

我的经验不应该是下一个人的经验。