高性能一直是咱们做为程序员..孜孜不倦的追求..html
有的时候甚至会为了一句代码吵上几天..ios
那么到底应该如何评估咱们的性能指标来判断是否须要优化呢?程序员
今天就来说一下这个..编程
说明一下,本篇是译文.小程序
原文地址:https://stackify.com/application-performance-metrics/服务器
下面咱们就正式开始并发
Apdex 全称是 Application Performance Index,是由 Apdex 联盟开放的用于评估应用性能的工业标准。Apdex 联盟起源于 2004 年,由 Peter Sevcik发起。Apdex 标准从用户的角度出发,将对应用响应时间的表现,转为用户对于应用性能的可量化为范围为 0-1 的满意度评价。app
Apdex 定义了应用响应时间的最优门槛为 T,另外根据应用响应时间结合 T 定义了三种不一样的性能表现:编程语言
公式如图:工具
其中 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
这个,就不作过多解释了 - - ,嗯..字面意思很明白.
监控错误率也是关键的应用程序性能指标~
咱们通常有三种不一样的方式来跟踪应用程序错误:
在应用程序中,咱们可能会抛出并忽略数千个异常。
然而这些隐藏的应用程序异常一般会致使不少性能问题。
若是咱们的应用程序在云中升级并使用了伸缩弹性扩张服务.
请务必知道运行的服务器/应用程序实例数量。
伸缩弹性扩张服务确实能够帮助咱们确保应用程序的扩展以知足需求,并在非高峰时间节省不少成本.
可是,这也带来了一些独特的监控挑战。
举个栗子,若是咱们的应用程序根据CPU使用率自动升级,咱们可能看不到CPU变高。可是咱们会看到服务器实例的数量变高。(更不用说咱们的主机账单..正在嗖嗖嗖...烧钱!)
了解咱们的应用程序得到的流量会影响咱们的应用程序的成功与否。
请求率的增长或减小或多或少都会影响到其余各项性能指标.
Request请求率能够于与其余应用程序性能指标相关联,以了解应用程序扩展的动态。
监控请求率也能够很好地观察峰值和一些不活动的API。若是你有一个请求量很大的API忽然没有请求率,这应该是一件很是糟糕的事情,要注意。
固然你也能够根据这些数据来跟踪和发现本身的并发用户数量.
若是咱们的服务器上的CPU使用率很是高.
咱们能够保证咱们的应用程序性能出现了的问题。(这是句废话 - -,)
因此监控应用程序服务器CPU的使用状况是一个基本和关键的指标。
几乎全部的服务器和应用程序监视工具均可以跟踪我咱们的CPU使用状况并提供监控警报。
由于每一个服务器它们是很重要的.
监控和测量咱们的应用程序是否在线而且可用也是咱们应该跟踪的关键指标。
大多数公司使用它来衡量服务级别协议(SLA)的正常运行时间。
若是您有Web应用程序,则经过简单的定时HTTP检查小程序,来监视应用程序可用性是最简单的方法。
你能够每分钟为你运行这些类型的HTTP“ping”检查。
它能够是监视响应时间,状态代码,也能够是查找页面上的特定内容。
若是咱们的应用程序是用.NET,C#或其余使用GC编程语言编写的,
那么咱们要提早会意识到可能会产生的性能问题。
垃圾回收发生时,可能致使咱们的进程挂起并占用不少CPU。
垃圾回收指标虽然不是咱们对关键性能指标的首选项。
可是这多是一个隐藏的性能问题,始终是一个很好的主意,要注意。
对于.NET,您能够经过性能计数器“% GC Time”来监控这一点。Java经过JMX指标具备相似的功能。Retrace能够经过其应用程序指标功能监视这些内容。
前面说了这么多....那么做为咱们.NET er 的新宠.. .NETCore咱们如何监控他的8项性能指标呢?
监视效果以下:
咱们下一篇就来说..如何监控.Net Core应用程序..尽请期待..