应用程序的8个关键性能指标以及测量方法

前言

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

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

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

今天就来讲一下这个..

说明一下,本篇是译文.

原文地址: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应用程序..尽请期待..

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏华章科技

盘点:Java程序员在用的大数据工具

译文链接:http://www.codeceo.com/article/big-data-tools-java-programmer-use.html

422
来自专栏IT技术精选文摘

规模化时间序列数据存储(第一部分)

1373
来自专栏JAVA烂猪皮

你完全没了解过的日志异步落库

在互联网设计架构过程中,日志异步落库,俨然已经是高并发环节中不可缺少的一环。为什么说是高并发环节中不可缺少的呢? 原因在于,如果直接用mq进行日志落库的时候,低...

502
来自专栏SAP最佳业务实践

SAP最佳业务实践:生产订单拆分-按库存生产(248)-4订单拆分

image.png 订单拆分 选项 1:按相同物料拆分 使用此功能可以将一份现有生产订单拆分成多份订单,所有这些订单都用于生产相同的物料(但在开始日期和时间等...

2542
来自专栏坚毅的PHP

HBase 异步查询导致的死锁和zookeeper通信中断问题追踪与总结[非技术]

机房T和机房Y共十台前端机,Y机房请求量是T的两倍,主要用于数据查询,开始问题是Y机房tomcat 相继僵死 1) tomcat僵死处理步骤 a 检查代码,发现...

3435
来自专栏杨建荣的学习笔记

MySQL中的double write(二)(r12笔记第17天)

MySQL里的double write是InnoDB的三大闪亮特性,另外两个是insert buffer 和自适应哈希,其实还有几个比如异步IO,Flu...

3059
来自专栏CSDN技术头条

五个解决方案让MongoDB拥有RDBMS的鲁棒性事务

【编者按】在分布式存储解决方案中谈事务一直是件很痛苦的事情,而事务也成了大部分NoSQL解决方案短板所在。近日,MongoDB公司的Antoine Girbal...

1825
来自专栏逸鹏说道

Stack Overflow 2016最新架构探秘

这篇文章主要揭秘 Stack Overflow 截止到 2016 年的技术架构。   首先给出一个直观的数据,让大家有个初步的印象。   相比于 2013 ...

2867
来自专栏IT技术精选文摘

将单体应用重构为微服务

微服务重构概述 将单体应用程序转换为微服务的过程是应用程序现代化的一种形式。这是几十年来开发人员一直在做的事情。因此,在将应用程序重构为微服务时,有一些方法可以...

2118
来自专栏腾讯开源的专栏

腾讯 Node.js 非侵入开发框架 Tars.js 2.0 正式发布

692

扫码关注云+社区