在没有应用性能管理工具（APM，即application performance management ）的时候，当我们需要对应用优化，我们就需要不断的调试、阅读源码才能找到问题。如果这是一个多人协作的项目，对项目进行优化的难度，也会随着代码量的升高而不断加大。而了解应用性能瓶颈的最好方法就是：查看程序中运行时间最长的部分。在这时，我们就可以考虑使用性能管理工具来分析应用的性能。
这些性能管理工具运行在应用低一层的底层——语言层面，在应用运行的时候，他们的探针就会开始运行，并不断地收集应用的数据。这些数据将会被收集起来，发送给系统后台，这时我们就可以在后台上了解应用的运行状况。性能管理工具会分析应用的五个维度：
- 终端用户体验监控，分析用户加载、渲染时间等等有关于用户体验的事项。
- 应用运行时架构，监控应用程序的所有节点和服务器等等。
- 用户自定义的事务分析，监控用户自定义的事务，或者一些与业务相关的 URL 页面定义等等。
- 应用组件监控，对应用程序的中间件进行监控。
- 报告及应用数据分析，为应用程序提供度量和报告，并对其进行可视化。
同时，性能管理工具将使用应用性能指数（英语 Apdex，全称：Application Performance Index），来衡量用户对于应用性能的满意值。
Apdex 定义了应用程序响应的最优时间为 T，同时根据这个目标时间 T 定义了三种不同的性能表现：
- 满意：应用响应的时间低于或等于目标时间（T秒），用户的工作不会因为加载时间过长而受阻。
- 可容忍：用户感觉到响应滞后，响应时间大于目标时间（T秒），但是用户能忍受这个过程。
- 挫折：响应时间大于四倍的目标时间（T秒），用户无法忍受这个过程，便会离开网页。
下面我们将 New Relic 作为应用性能管理工具，来分析和展示应用程序的性能。
使用 New Relic 进行优化
New Relic 是国外知名的监控服务商，它可以实时地对应用进行监控和分析。我们选择使用 New Relic 的主要原因是，它提供了一个免费的、无期限基础版本。对于一般的小型 Web 应用来说，这个免费版本就够用了，这个版本里包含了一般应用需要的：吞吐量、应用响应时间、错误报告、数据库度量等等的功能。专业版里提供了一些高级的功能，这些功能更适合于中、大型的 Web 应用，如部署追踪、服务地图、衡量负载报告等等的功能。
由于我们的应用在线上的数据比较少，我将继续使用我的博客（https://www.phodal.com/）的数据来展示：如何用 New Relic 来进行分析。我博客也是基于 Django 来开发的，因此不需要担心与这里内容不符合的问题。博客每天的访问量在 500 左右，因些数据本身也是足够用的。
New Relic 安装
在开始之前，我们希望读者已经注册好了一个 New Relic 账号，注册地址：https://newrelic.com/signup。
登录 New Relic 之后，我们就可以集成 New Relic 到我们的应用里。New Relic 可以支持基于 Ruby、PHP、Java、.NET、Python、Node.js、Go 等语言或者技术的应用，我们使用的是 Python，选择完后就可以开始进行相关的设置。这个设置的过程是：
- 获取一个密钥
- 再用这个密钥生成一个配置文件
- 重新运行我们的应用
如官网的步骤所示：
我们在网页端获取密钥，随后安装 newrelic 的库
sudo pip install newrelic
再根据我们的密钥来生成相应的配置文件，命令如下：
newrelic-admin generate-config <your-key-goes-here> newrelic.ini
可以将我们的配置文件放到项目的相应位置，然后我们就可设置这个环境变量，并运行程序：
export NEW_RELIC_CONFIG_FILE=newrelic.ini
newrelic-admin run-program gunicorn -w 2 growth_studio.wsgi
这里的 newrelic-admin run-program就会在我们的应用与语言的底层之间，创建一个钩子（Hook）来监听应用对函数的调用等等的内容。在我们完成设置的几分钟过后，我们就可以在后台看到我们的数据，并根据这些数据来分析应用的情况。
使用 New Relic 分析应用
现在我们可以打开 New Relic 的后台来，在 APM 页面我们就可以看到应用信息的基本信息：
如图所示，左侧是服务端处理的响应时间，即从我们的应用接受到请求，到返回 HTML 给 HTTP 服务器的时间。图中分为两个颜色：较大的那部分是 Python 语言运行的时间，即运行我们的应用逻辑所说的时间：平均每个请求大概需要 200 ms 左右。而数据库相关部分则需要花费 30+ ms。图中的右上部分：显示的就是 Apdex 值，右下则显示的是网站的吞吐量。
对于大型应用来说，其瓶颈应该是相反的：即处理数据库花费更长的时间，而应用花费的时间会更短。对于我的博客来说，因为服务器性能的问题，所以运行逻辑代码的时间会比较长一些。
在概览的下方，我们就能看到页面的处理函数及服务器响应时间的关系，如下图所示：
从图中，我们就可以看到不同函数的处理时间。图中 mezzanine.blog.views 模块中的 blogpostlist 函数处理请求需要 690 ms，这个页面是博客的列表页。因此我们就能针对性的，了解一下为什么这个方法需要这么多的时间？于是，我们就可以点击进入这个函数的详细信息，就可以得到类似下图的一个分析页：
从上图中，我们就可以看到 blog_post_list_post_content块花费了相当多的时间来执行。
除了上面的应用性能分析，New Relic 还可以查看页面的渲染时间。与 Google Analytics 相比，New Relic 在分析渲染时间的粒度上会更细。如下图所示：上面的表格说明了，我们的应用时间主要花费在渲染页面上。在我们的列表页上，我们需要渲染多篇博客、关键字信息、按时间来分类等等的信息，因此需要比较长的时间。同时，这也说明了这个页面还有优化的空间。尽管我们无法避免用户访问这个页面，但是我们可以使用缓存等等的方法，来尽量减少执行这个方法的次数。这样一来，我们就可以大大地提高应用的性能。
上图中的加载时间，分为了四部分：
- 应用程序的处理时间
- 网络传输时花费的时间
- DOM 解析时间
- 页面渲染的时间
由于网络原因，这个渲染时间并不是那么准确。建议读者参考就好了，或者关注于类似 PageSpeed 这样的网页性能优化。
节选自《全栈应用开发：精益实践》第七章《数据分析和性能优化》
亚马逊：https://www.amazon.cn/dp/B0722YJR89
