linux下网站开发,鞍山信息港招聘信息,网站制作案例策划,网站载入页面怎么做前言
高性能一直是我们作为程序员..孜孜不倦的追求..
有的时候甚至会为了一句代码吵上几天..
那么到底应该如何评估我们的性能指标来判断是否需要优化呢?
今天就来讲一下这个..
说明一下,本篇是译文.
原文地址:https://stackify.com/application-performance-metrics/
…前言
高性能一直是我们作为程序员..孜孜不倦的追求..
有的时候甚至会为了一句代码吵上几天..
那么到底应该如何评估我们的性能指标来判断是否需要优化呢?
今天就来讲一下这个..
说明一下,本篇是译文.
原文地址:https://stackify.com/application-performance-metrics/
下面我们就正式开始 正文
1.用户满意度/ Apdex分数
Apdex 全称是 Application Performance Index是由 Apdex 联盟开放的用于评估应用性能的工业标准。Apdex 联盟起源于 2004 年由 Peter Sevcik发起。Apdex 标准从用户的角度出发将对应用响应时间的表现转为用户对于应用性能的可量化为范围为 0-1 的满意度评价。
Apdex 定义了应用响应时间的最优门槛为 T另外根据应用响应时间结合 T 定义了三种不同的性能表现
Satisfied满意应用响应时间低于或等于 TT 由性能评估人员根据预期性能要求确定比如 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 ms30 次应用响应时间处于 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.垃圾回收
如果我们的应用程序是用.NETC或其他使用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跨平台或扫描二维码关注
