前言

高性能一直是我们作为程序员..孜孜不倦的追求..

有的时候甚至会为了一句代码吵上几天..

那么到底应该如何评估我们的性能指标来判断是否需要优化呢?

今天就来讲一下这个..

说明一下,本篇是译文.

原文地址:https://stackify.com/application-performance-metrics/

下面我们就正式开始

 

 

正文

1.用户满意度/ Apdex分数

Apdex 全称是 Application Performance Index，是由 Apdex 联盟开放的用于评估应用性能的工业标准。Apdex 联盟起源于 2004 年，由 Peter Sevcik发起。Apdex 标准从用户的角度出发，将对应用响应时间的表现，转为用户对于应用性能的可量化为范围为 0-1 的满意度评价。

Apdex 定义了应用响应时间的最优门槛为 T，另外根据应用响应时间结合 T 定义了三种不同的性能表现：

• Satisfied（满意）：应用响应时间低于或等于 T（T 由性能评估人员根据预期性能要求确定），比如 T 为 1.5s，则一个耗时 1s 的响应结果则可以认为是 satisfied 的。

• Tolerating（可容忍）：应用响应时间大于 T，但同时小于或等于 4T。假设应用设定的 T 值为 1s，则 4 * 1 = 4 秒极为应用响应时间的容忍上限。

• Frustrated（烦躁期）：应用响应时间大于 4T。

公式如图:

 

其中 Satisfied Count 就是指定采样时间内响应时间满足 Satisfied 要求的应用响应次数；而 Tolerating Count 就是指定采样时间内响应时间满足 Tolerating 要求的应用响应次数；最后的 Total Samples 就是总的采样次数总数。从公式可以看出，应用的 Apdex 得分与采样持续时间无关，与目标响应时间 T 相关（在采用总数固定的情况下，T 通过影响 Satisfied Count以及 Tolerating Count的值间接影响最终的得分）。

 

 

假设你的应用期待的响应时间能够在 1000 ms 内，在 100 次采样中，有 50 次应用响应时间低于 1000 ms，30 次应用响应时间处于 1000 ms 到 4000 ms（ 4 * 1000ms） 之间，剩下 20 次响应时间长于 4000 ms，那么，该应用在 T = 1000ms 的情况下的 Apdex 值为：

(50 + 30 / 2) / 100 = 0.65

  

2.平均响应时间

这个,就不做过多解释了 - - ,嗯..字面意思很明白.

 

3.错误率

监控错误率也是关键的应用程序性能指标~

我们一般有三种不同的方式来跟踪应用程序错误：

• HTTP错误百分比 - 以错误结束的Web请求数量占的比例.

• 已记录的异常 - 应用程序中未处理和记录的错误的数量

• 抛出的异常-所有已被抛出的异常

在应用程序中，我们可能会抛出并忽略数千个异常。

然而这些隐藏的应用程序异常通常会导致很多性能问题。

4.应用实例计数

如果我们的应用程序在云中升级并使用了伸缩弹性扩张服务.

请务必知道运行的服务器/应用程序实例数量。

伸缩弹性扩张服务确实可以帮助我们确保应用程序的扩展以满足需求，并在非高峰时间节省很多成本.

但是,这也带来了一些独特的监控挑战。

举个栗子，如果我们的应用程序根据CPU使用率自动升级，我们可能看不到CPU变高。但是我们会看到服务器实例的数量变高。（更不用说我们的主机帐单..正在嗖嗖嗖...烧钱！）

 

5.Request请求率

了解我们的应用程序获得的流量会影响我们的应用程序的成功与否。

请求率的增加或减少或多或少都会影响到其他各项性能指标.

Request请求率可以于与其他应用程序性能指标相关联，以了解应用程序扩展的动态。

监控请求率也可以很好地观察峰值和一些不活动的API。如果你有一个请求量很大的API突然没有请求率，这应该是一件非常糟糕的事情,要注意。

当然你也可以根据这些数据来跟踪和发现自己的并发用户数量. 

 

6.应用程序和服务器CPU

如果我们的服务器上的CPU使用率非常高.

我们可以保证我们的应用程序性能出现了的问题。(这是句废话 - -,)

所以监控应用程序服务器CPU的使用情况是一个基本和关键的指标。

几乎所有的服务器和应用程序监视工具都可以跟踪我我们的CPU使用情况并提供监控警报。

因为每个服务器它们是很重要的.

 

7.应用可用性

监控和测量我们的应用程序是否在线并且可用也是我们应该跟踪的关键指标。

大多数公司使用它来衡量服务级别协议（SLA）的正常运行时间。

如果您有Web应用程序，则通过简单的定时HTTP检查小程序,来监视应用程序可用性是最简单的方法。

你可以每分钟为你运行这些类型的HTTP“ping”检查。

它可以是监视响应时间，状态代码，也可以是查找页面上的特定内容。 

8.垃圾回收

如果我们的应用程序是用.NET，C＃或其他使用GC编程语言编写的，

那么我们要提前会意识到可能会产生的性能问题。

垃圾回收发生时，可能导致我们的进程挂起并占用很多CPU。

垃圾回收指标虽然不是我们对关键性能指标的首选项。

但是这可能是一个隐藏的性能问题，始终是一个很好的主意，要注意。

对于.NET，您可以通过性能计数器“％ GC Time”来监控这一点。Java通过JMX指标具有类似的功能。Retrace可以通过其应用程序指标功能监视这些内容。 

 

结束语

前面说了这么多....那么作为我们.NET er 的新宠.. .NETCore我们如何监控他的8项性能指标呢?

监视效果如下:

 

我们下一篇就来讲..如何监控.Net Core应用程序..尽请期待..

相关文章： 

• 互联网级监控系统必备-时序数据库之Influxdb技术

• 互联网级监控系统必备-时序数据库之Influxdb集群及踩过的坑
  

原文地址：http://www.cnblogs.com/GuZhenYin/p/7161480.html

---

.NET社区新闻，深度好文，微信中搜索dotNET跨平台或扫描二维码关注