在 Laravel 中使用 Inspector 识别性能问题

介绍

性能是一个网站应用程序的重要部分。运行缓慢的应用程序可能会让用户感到沮丧，导致糟糕的用户体验。如果您的网站主要目标是把流量转化为付费客户（比如SaaS应用程序或电子商务商店），那么这可能会造成收入损失。

糟糕的应用程序性能还可能导致在您的基础设施上花费更多，因为您可能需要添加更多资源（如更多的服务器或数据库实例）来处理增加的负载。如果您使用的是无服务器系统，比如AWS Lambda，这可能更为明显，因其运行时间越长，成本越高。

因此，了解您应用程序的性能概述非常重要。如果您的应用程序开始变慢，您需要知道哪些部分运行缓慢以及原因。但是，如果没有正确的工具和数据，可能很难知道从哪里开始。这时应用程序性能监控（APM）就派上用场了。

在本文中，我们将探讨应用程序性能监控是什么，以及使用它的好处。我们还将探讨如何使用Inspector这种APM服务来识别Laravel应用程序中的性能瓶颈。

什么是应用程序性能监控（APM）？

应用程序性能监控（APM）是指监控系统应用程序性能的过程——正如其名。这可能包括监控系统应用程序的速度、它处理的请求数量以及它使用的资源。根据您如何监控应用程序的性能，您还可能能够深入到请求的生命周期中，查看每一部分需要多长时间。例如，您可能可以获取以下方面的概述：

您的应用程序启动需要多长时间
数据库查询需要多长时间
渲染视图需要多长时间
应用程序中某些逻辑运行需要多长时间

使用正确的工具，所有这些都可以被监控，这样您就可以看到应用程序哪些地方正在减慢速度。然后，您可以使用APM的结果来识别性能瓶颈并修复它们。

什么是检查器（Inspector）？

您可以使用的一种用于监控应用程序性能的在线工具是名为“Inspector”的工具。

Inspector是一种APM服务，允许您监控Laravel应用程序的

HTTP请求
Artisan命令
作业/队列
后台任务

使用Inspector启动起来非常容易，他们甚至提供免费层级。所以，如果您不确定它是否适合您，您无需任何财务投入即可试用，这真是太酷了！

要使用它，您只需要将Inspector包安装到您的Laravel应用程序中，并将您的Inspector API密钥添加到您的.env文件中。然后它将开始收集数据以监控应用程序的性能。我们将在文章的后面回到这个话题。

首先，我们需要了解使用APM服务的优势（尤其是如果您想要说服您的老板或客户让您开始使用它的话！）。

应用程序性能监控的优势

使用APM服务，如Inspector，可以为您带来几个好处，包括

使用真实数据获得更真实的主观印象

您听过多少次有人说“今天应用程序运行得真的很慢”？

通常您必须相信他们并盲目地调查问题，希望再次遇到相同的问题。但是，性能问题并不总是始终如一，并且很难再现。它们并不像可以在您的本地机器上复现或自动报告给您的日志或错误跟踪系统的错误。

您可以采取的一个方法是在系统中找出经历问题的用户/租户/团队，然后在您的本地机器上创建大量数据（使用如工厂和种子器之类的工具）以尝试匹配相同的条件。但这通常非常繁琐，除非您有一些非常深入的种子器和工厂，否则很难匹配相同的条件。实际的真实数据始终会好于随机生成的数据，因为它代表您应用程序的实际条件。

您还可以采用的方法之一是从生产数据库中复制一份，并在本地机器上导入。这肯定会为您提供一个更接近现实的数据集来工作。但请注意这种方法！这需要您在应用程序之外连接到生产数据库，这可能导致错误（如意外删除或更新数据）。此外，也存在隐私风险，因为您可能会在本地机器上存储敏感数据或个人可识别信息（PII）。除非您有充分的理由这么做，或者至少有匿名化数据的方法，否则我建议不要采用这种方法。

以上两种方法仅适用于数据问题。如果问题是与数据无关，是由其他因素（如运行缓慢的数据库服务器）引起的，则上述方法将不会有帮助。

这时，APM服务（如Inspector）就可以大显身手了。它可以在生产应用程序的后台无缝运行，并收集真实性能数据。这意味着当有人报告性能问题时，您可以查看数据以调查问题的原因。

这可以节省大量时间，并帮助您更快地找出问题的原因。

提高SEO和用户体验

页面加载速度是搜索优化（SEO）和用户体验的重要因素。如果您的网页加载缓慢，可能会导致用户沮丧，甚至可能使他们离开您的网站，转而访问竞争对手的网站。这可能导致收入损失。

因此，谷歌根据 Semrush 的说法，将页面加载时间用作谷歌的排名因素。这意味着如果您的页面加载缓慢，您可能不会在搜索结果中获得理想的排名。

Semrush 在其文章中还提到，根据谷歌，“页面加载时间超过三秒钟，跳出率几乎会翻三倍。”

因此，了解您应用程序的性能概述，您可以识别出响应较慢的请求，并将它们优化。这可以降低被谷歌惩罚的可能性，并提高用户体验。

识别需要重构的代码

当您最初构建应用程序时，可能只设想会有很少的用户数量。因此，您可能以易于处理少量用户的方式来编写代码，但可能不适合处理大量用户。

在我看来，这并没有什么不妥。编写能够扩展到大量用户的代码与编写能够处理少量用户的代码可能有很大不同。有时候，不同的方法可能需要不同的思考方式。所以如果您预期您的应用程序的用户数量不会超过100人，那么编写能够处理10万名用户的代码可能就有点过度了。

当然，这并不意味着您有理由编写性能差的代码。您仍然需要为您的作品感到自豪。这只是为了说明，如果不需要，您可能不需要编写大规模可扩展的代码。

但假设您的应用程序开始增长。可能会到达这样一个时刻，您意识到您的初始方案可能不再有效。您可能有一些慢请求正在减慢应用程序的运行。

如果您没有亲身经历系统的缓慢，唯一知道您需要重构代码的方式可能是收到用户的投诉。但那时可能已经太晚了。您可能已经失去了一些用户，可能会形成不良声誉。

但是，通过使用APM服务，您可以查看系统历史记录，并注意到处理请求数据量逐渐增加。然后您可以使用这些数据来识别瓶颈所在，并重构代码以提高速度，使其更适应增加的负载。

作为一个小贴士，如果您正在寻找改进Laravel代码的方法，您可能会对我在《Battle Ready Laravel》一书中所展示的内容感兴趣，它演示了如何审计、测试、修复和改进您的Laravel应用程序。

使用APM服务的另一个好处是，您还可以比较重构前后应用程序的性能。这有助于您了解重构过程是否产生了效果。

向利益相关者、老板或客户说明重构的必要性

如上所述，您可以使用APM服务的数据来向利益相关者、老板或客户证明重构的必要性。

对于许多开发者来说，消除技术债务或重构代码是他们希望做的事，但很多时候很难向持有人证明这一点。特别是如果代码正在运行且用户没有任何投诉时，这一点尤为如此。很难证明在看似没有问题的东西上花费时间和金钱的合理性。

然而，通过使用APM服务，您可以收集数据和统计数据，以有力地论证为什么需要重构代码。大致可以是这样的说法：“一切现在都在运行，但几个月后，我们很可能会开始看到很多问题。”

事实和数据永远比仅仅说“我认为我们应该重构这段代码”更有说服力。

因此，能够提前发现性能瓶颈和潜在的中断可以带来巨大的好处。

服务级别协议（SLA）合规

当您的Web应用程序出售给客户时，您可能已经同意了一个服务级别协议（SLA）。这是一个定义您所期望提供的服务水平的合同，这可能包括诸如正常运行时间、响应时间和可处理请求数量等事项。

通过使用APM服务，您可以监控应用程序的性能，以确保您符合SLA的要求。如果您正在为客户提供服务并收取大量费用，这尤其重要。您不希望处于不符合SLA而自己却没意识到的情况。

使用Inspector与Laravel集成

现在我们有了对Inspector的了解和APM服务的使用好处概述，让我们看看如何在使用Laravel应用程序中使用Inspector。

安装

在我们接触任何代码之前，您首先需要在Inspector中注册一个账户。您可以通过访问以下网址来完成此操作：https://app.inspector.dev/register。

注册后，您希望然后在Inspector中创建一个新“应用程序”。请确保选择“Laravel”作为应用程序类型。

完成此操作后，我们就可以将Inspector Laravel包安装到您的应用程序中。您可以在项目根目录中运行以下命令来完成此操作

composer require inspector-apm/inspector-laravel

安装包后，您需要在.env文件中添加您的Inspector API密钥（此API密钥将在Inspector仪表板上显示）。以下是这样添加的

INSPECTOR_INGESTION_KEY=your-api-key-here

随后，您需要在app/Http/Kernel.php文件中添加Inspector的中间件。这是负责收集应用程序性能数据的代码。您可以通过以下方式将其添加到$middlewareGroups数组中

/**
  * The application's route middleware groups.
  *
  * @var  array
  */
protected $middlewareGroups = [
    'web' => [
        // ...,
        \Inspector\Laravel\Middleware\WebRequestMonitoring::class,
    ],

    'api' => [
        // ...,
        \Inspector\Laravel\Middleware\WebRequestMonitoring::class,
    ]
]

完成了！现在应该已经安装好Inspector并准备好开始报告应用程序的性能数据。

为了确保已经正确安装并运行，你可以运行随包提供的命令，以确保它正在正常工作。您可以通过在终端中运行以下命令来完成此操作：

php artisan inspector:test

现在您可以访问Inspector仪表板，查看正在收集的有关应用程序性能的数据。

监控请求

现在Inspector已经安装并运行，您需要等待一些数据传入，才能开始比较请求。根据您的应用程序，您可能希望像其他任何用户一样操作应用程序来进行此操作。或者，您可能想要等待几小时、几天或几周，让数据自然传入。

最好记住，您拥有的数据越多，对应用程序性能的洞察就越好。

比较请求

我将Inspector留在我个人博客上运行了几天，看看我会得到什么数据以及我能从中获得哪些洞察。

注意：在图表中，您会注意到收集数据的突然下降。这是因为我在使用免费版时用完了当月的交易量。

在下图中，我们可以看到Inspector为我博客收集的数据。它显示了不同路由请求的平均执行时间。此外，它还显示了其他有用的信息，例如事务数（在本例中，这些是对路由的请求）、每个路由的平均执行时间和平均使用的内存量。

通过使用以上图表中的数据，我们可以看到`/blog/{post}`路由是博客上访问最多的路由。这是负责显示博客文章的路由。我们还可以看到平均执行时间相对一致，但在2024年2月20日平均执行时间有一个高峰。这可能是我们想要调查的事情。

Inspector还提供了一个图表，提供了有关在任何给定时间段内交易数量的信息。这些信息与平均执行时间的匹配可能很有用。例如，您可能会发现平均执行时间在交易数量达到高峰时也会出现高峰。

然后，Inspector允许您深入查看特定路由，以查看对该路由的请求性能。在我们的案例中，我们将查看`/blog/{post}`路由。

下图显示了`/blog/{post}`路由的平均执行时间

在图像中，您看不到具体的数字（它们仅在悬停在图表的条上时显示），但我可以告诉您，`/blog/{post}`路由在3天内接收了5492个请求。以下是请求到路由的平均执行时间的分解

0-85ms - 5241个请求
85-170ms - 170个请求
170-255ms - 59个请求
255-340ms - 17个请求
340-425ms - 3个请求
425ms+ - 2个请求

正如我们所见，大多数请求都在合理的时间内处理完毕。但还有一些请求处理时间较长。这可能是我们想要调查的，看看是否可以做出改进。

为了本文的目的，我们将比较在0-85ms范围内处理的请求与在425ms+范围内处理的请求。我们这样做纯粹是为了展示Inspector如何用于比较请求并突出它们之间的差异。

在真实场景中，我会倾向于将更快请求与170-255ms范围内的请求进行比较。这通常是因为超过255ms后，请求的数量并不多。因此，超过255ms的请求可能是异常值，可能不值得调查。但这完全取决于你的应用程序。在这个例子中，我们只是在监测博客的性能，所以如果一篇文章的加载时间稍微长于其他文章，这并不是世界末日。但如果你正在与SaaS应用程序或电子商务商店合作，你可能想要调查超过255ms的请求。

在下图中，我们可以看到0-85ms范围内的请求（在左侧）与425ms以上范围内的请求（在右侧）的比较。

如我们在左侧所看到的，请求中最长时间的部分是渲染Blade视图，耗时12.28ms。这是负责向用户的浏览器发送HTML的部分。

然而，在右侧，我们可以看到请求中最长时间的部分是向session表插入新行的数据库语句，耗时371.93ms。

这很有用，因为它揭示了这种与数据库的特定交互是减慢请求的主要原因。在这个特定的例子中，我并不是太担心，因为这种情况只发生了两次。但如果这种情况发生得更频繁，我可能想要进一步调查。

慢请求的可能原因

正如我们简要提到的，有许多原因可能导致请求与其它请求相比速度较慢。

慢速或昂贵的数据库查询

你可能有一个运行在你应用程序中的慢速数据库查询（如我们上面的例子）。这可能是因为缺少索引、运行慢的数据库服务器或处理大量数据。

也可能是你在进行大量的数据库查询，这可能可以通过预加载或使用缓存存储一些数据来改善。

慢速或昂贵的API请求

如果你的应用程序在调用外部API时变慢，可能会影响速度。不幸的是，外部API的性能不受你的控制。但，根据API和请求的性质，你可能能够在应用程序中实现一些性能改进。

例如，假设你正在使用Mailgun向500个用户发送邮件。与其向Mailgun发送500个API请求发送邮件（为每个接收者发送一次API请求），你可能会使用Mailgun的批量发送功能来在单个请求中发送所有邮件。这将减少你的应用程序向Mailgun发送的请求数量，并可能加快处理速度。

另一种减轻外部API对你的项目速度影响的方法可能是利用你的Laravel应用程序的缓存（使用Laravel应用程序的缓存）。例如，假设你想要获取过去某一日期的货币兑换率。你可以向API请求获取兑换率，并将其存储在缓存中。这意味着下次你需要检查那个日期的交换率时，你可以从缓存中获取，而无需再次向API发出请求。

旁白：如果你对学习如何使用 Saloon 在 Laravel 中构建健壮、强大且可测试的 API 集成感兴趣，你可能会对我的那本 440 多页的书籍感兴趣，书名为《在 Laravel 中消费 API》。