对于我们开发来说，我们日常最熟悉的工作就是把客户的需求实现并交付。但是，事情并不是往往就这样结束了，我们还需要后续对上线的系统进行跟踪调查，查看系统的运行情况。为什么呢？一方面，我们需要关注系统在运行过程中的健康问题，是否有异常等等；另一方面我们需要了解系统性能和容量是否能满足用户的日常访问。只有去了解线上系统的运行状况，才能让为后续项目提供参考，及早的调节以避免故障问题。
对于应用系统在线上出现的异常，我们可以通过监控系统的日志扫描或者一些监控api来进行异常监控。比如可以通过应用的监控系统来查看。对于性能方面，我们有哪些性能指标去关注呢，下面列出了几个在监控系统中最常用的性能指标。
PV
PV是 Page View的缩写。用户通过浏览器访问页面，对应用服务器产生的每一次请求，
记为一个 PV。淘宝性能测试环境下，将这个概念做了延伸，系统真实处理的一个请求，视
为一个 PV。即，PV的概念也适用于接口。
PV的统计一般可以通过监控埋点或者统计访问日志统计得出。
说到PV还有个特殊的情况，叫PeakPV，指一天中 PV数达到的高峰PV值。
通过一些监控系统，也可以直观看到统计数据。
QPS/TPS
QPS/TPS原本含义为：系统每秒能处理的请求/事务的数量，或者说吞吐量。在web应用我们更关注的是web应用每秒能处理的request数量。这个是衡量系统性能的重要指标。
QPS（TPS）= 并发数/平均响应时间。
QPS的统计可以通过访问日志统计对应时间的PV量除以对应时间求得。在性能测试中可以通过工具测试获得。
一般经常统计的是高峰期PV对应的QPS。
ResponseTime响应时间
响应时间(RT)是指从客户端发一个请求开始计时，到客户端接收到从服务器端返回的响应结果结束所经历的时间，响应时间由请求发送时间、网络传输时间和服务器处理时间三部分组成。
LOAD负载
系统平均负载，被定义为在特定时间间隔内运行队列中的平均进程数。如果一个进程满
足以下条件则其就会位于运行队列中：
-它没有在等待 I/O操作的结果
-它没有主动进入等待状态（也就是没有调用'wait'）
-没有被停止（例如：等待终止）1
这个负载值比较理想的指标值是cpu个数*核数*0.7 ，如果超过长期超过过这个值就需要对系统进行警惕了。
CPU 资源
CPU 资源这里指应用服务系统的 CPU 资源占用率。CPU 资源是判断系统处理能力以及应用运行是否稳定的重要参数。
JVM GC和FullGC
对于java应用的性能指标必定少不了GC的相关指标了。通常我们的应用应该尽量避免FGC。因为FGC会进行完全的垃圾清理，会使应用运行得很慢，所以需要通过设置合适的JVM参数和GC策略来避免FGC。通常监控的指标有GC次数和响应时间。
常用的性能指标还有内存占用，磁盘io等一些指标，这里就不一一列出。
上面介绍了一些性能指标的概念和统计方法，下面就讲其中几个之间的一些重要联系和区别。
1. 容量预测
对于我们设计的系统，我们在上线前肯定需要测试下能接收用户多大的访问量。即希望评估出最大的日PV到来的时候，我们的系统是否能支撑。但怎么去评估呢，难道要造一个最大日pv的情景来测试？其实根据已有的经验和数据，可以总结出了高峰QPS和日pv的关系。
我们通过每日的QPS和PV统计图表可以发现，每日的曲线基本都是一致的。通过数学建模，我们可以发现高峰每台服务器QPS=( (总 PV*80%)/(24*60*60*40%))/服务器数量1。其中80%和40%这2个数字是个不固定的参数，这个公式代表的意思是，在40%的时间（12小时）内产生80%总pv的QPS均值。对于不同的情景有不同的参数。
这样我们就可以通过压测应用获取其高峰QPS，然后根据公式算出指定高峰QPS下的日PV，通过这样来进行容量预测。
即：日预估PV=压测QPS * （24*60*60*时间百分比）/0.8 * 机器数量
2. CPU 资源占用率 与 LOAD
按很多人的印象cpu占用率和load都是对当前cpu使用率的统计。但是实际上这2个指标还是有很大区别的。
cpu占用率很好理解，就是对cpu使用所占时间比率。而cpu load则是基于一段时间内等待cpu处理的任务队列的平均长度。这个指标在高负载的情况下比cpu占用率具有更高的参考价值。因为在高负荷时段，cpu的占用率基本都接近100%，它无法反映机器负荷的程度。相反，通过统计任务队列的长度可以反映出系统目前负荷是否严重，是否可控。
用下图中公路与车辆的关系可以很好理解load的概念：
(系统是单处理器时)
当load等于1的时候，系统满负荷，但是能满足当前的系统需求；
当load小于1的时候，系统轻松运行；
当load大于1时候，有很多车辆等待进入公路，就如任务在等待cpu处理一样，这时候cpu占用率根本无法分辨出load=1和load>1这2种情况。
所以读懂load对于理解系统当前运行负荷是很有帮助的。
对于应用系统在线上出现的异常，我们可以通过监控系统的日志扫描或者一些监控api来进行异常监控。比如可以通过应用的监控系统来查看。对于性能方面，我们有哪些性能指标去关注呢，下面列出了几个在监控系统中最常用的性能指标。
PV
PV是 Page View的缩写。用户通过浏览器访问页面，对应用服务器产生的每一次请求，
记为一个 PV。淘宝性能测试环境下，将这个概念做了延伸，系统真实处理的一个请求，视
为一个 PV。即，PV的概念也适用于接口。
PV的统计一般可以通过监控埋点或者统计访问日志统计得出。
说到PV还有个特殊的情况，叫PeakPV，指一天中 PV数达到的高峰PV值。
通过一些监控系统，也可以直观看到统计数据。
QPS/TPS
QPS/TPS原本含义为：系统每秒能处理的请求/事务的数量，或者说吞吐量。在web应用我们更关注的是web应用每秒能处理的request数量。这个是衡量系统性能的重要指标。
QPS（TPS）= 并发数/平均响应时间。
QPS的统计可以通过访问日志统计对应时间的PV量除以对应时间求得。在性能测试中可以通过工具测试获得。
一般经常统计的是高峰期PV对应的QPS。
ResponseTime响应时间
响应时间(RT)是指从客户端发一个请求开始计时，到客户端接收到从服务器端返回的响应结果结束所经历的时间，响应时间由请求发送时间、网络传输时间和服务器处理时间三部分组成。
LOAD负载
系统平均负载，被定义为在特定时间间隔内运行队列中的平均进程数。如果一个进程满
足以下条件则其就会位于运行队列中：
-它没有在等待 I/O操作的结果
-它没有主动进入等待状态（也就是没有调用'wait'）
-没有被停止（例如：等待终止）1
这个负载值比较理想的指标值是cpu个数*核数*0.7 ，如果超过长期超过过这个值就需要对系统进行警惕了。
CPU 资源
CPU 资源这里指应用服务系统的 CPU 资源占用率。CPU 资源是判断系统处理能力以及应用运行是否稳定的重要参数。
JVM GC和FullGC
对于java应用的性能指标必定少不了GC的相关指标了。通常我们的应用应该尽量避免FGC。因为FGC会进行完全的垃圾清理，会使应用运行得很慢，所以需要通过设置合适的JVM参数和GC策略来避免FGC。通常监控的指标有GC次数和响应时间。
常用的性能指标还有内存占用，磁盘io等一些指标，这里就不一一列出。
上面介绍了一些性能指标的概念和统计方法，下面就讲其中几个之间的一些重要联系和区别。
1. 容量预测
对于我们设计的系统，我们在上线前肯定需要测试下能接收用户多大的访问量。即希望评估出最大的日PV到来的时候，我们的系统是否能支撑。但怎么去评估呢，难道要造一个最大日pv的情景来测试？其实根据已有的经验和数据，可以总结出了高峰QPS和日pv的关系。
我们通过每日的QPS和PV统计图表可以发现，每日的曲线基本都是一致的。通过数学建模，我们可以发现高峰每台服务器QPS=( (总 PV*80%)/(24*60*60*40%))/服务器数量1。其中80%和40%这2个数字是个不固定的参数，这个公式代表的意思是，在40%的时间（12小时）内产生80%总pv的QPS均值。对于不同的情景有不同的参数。
这样我们就可以通过压测应用获取其高峰QPS，然后根据公式算出指定高峰QPS下的日PV，通过这样来进行容量预测。
即：日预估PV=压测QPS * （24*60*60*时间百分比）/0.8 * 机器数量
2. CPU 资源占用率 与 LOAD
按很多人的印象cpu占用率和load都是对当前cpu使用率的统计。但是实际上这2个指标还是有很大区别的。
cpu占用率很好理解，就是对cpu使用所占时间比率。而cpu load则是基于一段时间内等待cpu处理的任务队列的平均长度。这个指标在高负载的情况下比cpu占用率具有更高的参考价值。因为在高负荷时段，cpu的占用率基本都接近100%，它无法反映机器负荷的程度。相反，通过统计任务队列的长度可以反映出系统目前负荷是否严重，是否可控。
用下图中公路与车辆的关系可以很好理解load的概念：
(系统是单处理器时)
当load等于1的时候，系统满负荷，但是能满足当前的系统需求；
当load小于1的时候，系统轻松运行；
当load大于1时候，有很多车辆等待进入公路，就如任务在等待cpu处理一样，这时候cpu占用率根本无法分辨出load=1和load>1这2种情况。
所以读懂load对于理解系统当前运行负荷是很有帮助的。
性能指标还是有很多信息可以去挖的，本文从应用监控的角度出发进行了一个简单介绍。但是不可否认，读懂性能指标是每个应用负责人去了解系统运行状况的必要条件，也是每个开发应当关心的内容。
参考资料：
淘宝性能测试白皮书
系统吞吐量评估方法http://blog.csdn.net/fenglibing/article/details/6223197
理解 LINUX 的处理器负载均值 http://www.gracecode.com/archives/2973/
扫一扫
5万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
