性能监控与分析

关于性能

参考：http://blog.sina.com.cn/s/blog_61d758500102wnuq.html

http://www.cnblogs.com/yunman/p/5482163.html

我们说性能或者性能分析，说的是什么？分析的是什么？说的是资源使用情况。

什么是性能？性能描述的是什么，性能现象是什么？

性能指标有哪些？

性能监测工具、分析工具、测试工具

性能分析：资源使用，处理能力及限制边界。以上两方面反映了性能状况。

什么性能？

1、性能描述，性能表象，性能现象

性能瓶颈的表象：

1.资源消耗过多。什么资源？哪些资源？

2.外部处理系统的性能不足。

3.资源消耗不多，但程序的响应速度却仍达不到要求。

------------------------------------------------------------------------------------

程序运行状态需要监控，运维。为什么需要监控？我们需要知道了解程序的运行状态。物理机是有资源制约的，有限制边界的。哪些状态数据需要监控？物理机状态，物理机是有资源制约的。处理能力也是有上限的。

性能测试的目的主要有以下三点：

1）评价系统当前性能，判断系统是否满足预期的性能需求。例如上线性能要求。

2）判定系统的性能表现，预判系统负载压力承受力，知道系统的极限、上限，在应用部署之前，预判，评估系统性能。

3）寻找系统可能存在的性能问题，定位性能瓶颈并解决问题。

对于用户来说，最关注的是当前系统的运行状态：

1）当前系统的稳定性如何，可能的性能瓶颈？

2）系统极限、上限承载如何？

3）是否满足上线性能要求？

总结为三点：1、系统极限、上限；2、上线性能要求，性能需求，预判性能表现；3、瓶颈定位；

因此，针对以上性能测试的目的以及用户的关注点，要达到以上目的并回答用户的关注点，就必须首先执行性能测试并明确需要收集、监控哪些关键指标；通常情况下，性能测试监控指标主要分为：资源指标和系统指标，如下图所示，资源指标与硬件资源消耗直接相关，而系统指标则与用户场景及需求直接相关。

将要点流程化

1、性能监控需要关注哪些关键指标？

性能测试监控关键指标说明：

=>资源指标，与硬件资源消耗直接相关

CPU使用率：指用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85%。

内存使用率：内存利用率=（1-空闲内存/总内存大小）*100%，一般至少有10%可用内存，内存使用率可接受上限为85%。

磁盘I/O：磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是是读IO操作，一般使用% Disk Time（磁盘用于读写操作所占用的时间百分比）度量磁盘读写性能。

网络带宽：一般使用计数器Bytes Total/sec来度量，Bytes Total/sec表示为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较。

=>系统指标，与用户场景及需求直接相关

并发用户数：某一物理时刻同时向系统提交请求的用户数。
在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求。
平均响应时间：系统处理事务的响应时间的平均值。事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间。对于系统快速响应类页面，一般响应时间为3秒左右。
事务成功率：性能测试中，定义事务用于度量一个或者多个业务流程的性能指标，如用户登录、保存订单、提交订单操作均可定义为事务，如下图所示：

单位时间内系统可以成功完成多少个定义的事务，在一定程度上反应了系统的处理能力，一般以事务成功率来度量，计算公式如下所示：
超时错误率：主要指事务由于超时或系统内部其它错误导致失败占总事务的比率。

二、如何监控关键指标？

================================>资源指标监控

主要针对各服务器系统平台（Windows、Linux、Unix等）资源使用进行监控。

可以使用系统自带的性能监控工具或者第三方工具进行监控，如windows系统自带的“系统性能监视器”，如下图所示：

参考：http://blog.youkuaiyun.com/ab7434588/article/details/53023799

msconfig, perfmon

Linux系统下，free、vmstat、sar、iostat等命令监控内存、cpu、磁盘io等的使用情况，如下图所示：

第三方监控工具，如spotlight，spotlight是quest公司开发的一款可以针对多种系统平台及数据库进行监控的可视化工具，如下图所示：

Nmon是IBM提供的监控AIX和Linux系统资源的免费工具，可以对收集的资源信息通过Excel进行统计分析形成直观的统计图，如下图所示：

================================>系统指标监控

系统指标监控一般通过性能测试工具（如LoadRunner、Jmeter等）以图形化方式监控，如下图所示，并发用户数与平均响应时间关系图。

三、如何分析监控的关键指标数据？

通过第二部分监控收集到的性能度量关键指标，如何进行分析，并判断是否存在性能瓶颈呢？以下主要从资源指标与系统指标两方面进行阐述。

================================>资源指标分析

================================>系统指标分析

并发用户数：

平均响应时间：

事务成功率、超时出错率：

全链路压测

系统性能的两个最为基本的指标：吞吐量和响应时间。这两个指标适用于所有it设备，适用于所有it系统。一般来说，响应时间越快，吞吐量越高，但是随着吞吐量逐渐达到一个限制值之后，响应时间将迅速下降。也就是说，任何资源，设备或者服务其服务能力是有限制的，当达到限制的时候其服务能力将迅速下降。

吞吐量和响应时间，不同的业务系统其侧重点不同。对于在线交易系统，其业务系统的基本目标为：在可接受的响应时间范围之内吞吐量越大越好。换句话可以这样描述，一笔交易在可接受的响应范围之内应该尽可能的降低资源消耗，因为资源是有限的。

关于响应时间：http://www.cnblogs.com/fnng/archive/2012/07/01/2571990.html

响应时间是用户最为关心的。

作为一个用户，对吞吐量毫不关心，但响应时间却是用户感受系统性能的主要体现。响应时间包括：客户端请求传输-客户端收到响应，响应传输。

客户端-----网络传输----服务器。包括两次网络传输时间+服务器处理时间（请求等待时间+请求处理时间）。

网络传输时间：

系统处理时间：

响应时间定义：TTLB(Time To Last Byte)

实际的性能测试：

网络传输时间忽略不计，因为局域网可以忽略，只有服务器的处理时间。

真正的网络传输时间计算比较负责，同样的起点，终点。每次请求的中间路线是不一样的。

合理的响应时间：

2/5/10秒原则。

总结：响应时间可以只看作是服务器的响应时间，不考虑请求和响应的网络传输时间。

总请求数：这个是没有意义的，比如1个用户的1000次请求，对于服务端来说，同一时刻只有1个请求。

最高并发总请求数：这个才有意义，某一时刻到服务端的请求数。300个用户* 1000次，最高只会有300个并发请求，1000次只是保证服务端请求队列出去一个进来一个，保证队列是满的。

并发处理能力：这个是系统的处理能力。超出处理能力之外的并发请求只能排队。

300个并发用户数，那么对与服务器来说就是最高300个并发请求。每个用户收到响应之后才会有新请求。

300 * 1000:1000只是保证服务端处理的请求队列完整，一直保持300个请求。应用了排队理论。

关注并发数增长的情况下，吞吐率及响应时间的变化。

并发用户数、响应时间、吞吐率。

吞吐率：单位时间处理的请求数，req/second。

并发用户数不同于系统并发处理数。

用户只希望等待最少的时间；服务器希望支持高吞吐率。

注意：

1、TPS：有些地方TPS指的是服务器每秒处理的事务数。

2、吞吐率：服务器每秒返回的字节数。

何为压力：并发请求数。参考：http://www.cnblogs.com/pohome/articles/2073283.html

并发用户数、并发请求数、并发处理数。

并发用户数就是并发请求数。一个用户只有收到响应才能发送新请求。

并发处理数是服务端的处理能力，但是并发请求数是不能控制的，并发请求数是外部压力，并发处理数是衡量服务器能力的因素。并发请求过来之后并不是都能被并发处理，有一个请求等待，请求处理的过程。对于这些并发请求，可以用平均响应时间、吞吐率来衡量服务器的处理能力。

并发的概念：并发请求，还是并发处理能力。

性能监控---->性能分析，瓶颈分析---->优化---->报告，总结