性能方案
性能目标：
1、最大并发数
2、Quality of Service 服务的质量，在软件系统方面我们认为主要表现在请求的出错率，系统的load等。
3、最长响应时间
对于任何请求所能承受的最大响应时间。
4、TPS
每秒需要支持的最大事务数，最典型的指标是：“某页面最高需要支撑每秒7000次的访问次数”。
Throughput吞吐量： 吞吐率=吞吐量/测试时间
Hits per second点击量：点击率=点击量/测试时间
OA系统，总用户数10000人，希望并发用户达到200人，我应该如何设置压力场景测试？
测试压力估算时采用原则如下：
系统在线用户并发数取在线用户数的30%，即：200*30%=60
此次性能测试用户数分三个档次：50并发，100并发，150并发,200并发。
并分别对三种情况进行性能测试记录测试结果
并对测试结果进行分析，特别关注150并发时系统的性能。
系统响应时间判断原则（2-5-10原则）如下：
系统业务响应时间小于2秒，判为优秀，用户对系统感觉很好；
系统业务响应时间在2-5秒之间，判为良好，用户对系统感觉良好；
系统业务响应时间在5-10秒之间，判为及格，用户对系统可以接受；
系统业务响应时间超过10秒，判断为不及格，用户不能接受系统的响应速度；
设计思想：大量用户同时使用某个功能和长时间反复运行，以检查系统并发性能和长期运行的稳定性。
测试内容： 取几个普通用户日常办公中经常使用到的操作或场景，录制为一个脚本。
测试步骤： 使用性能测试工具Loadrunner运行负载测试，添加录制好的某一个场景脚本和分别加载50/100/150/200个虚拟用户进行并发测试。
场景类型：手动场景，通过制定要运行的虚拟用户数来管理负载测试
场景计划名：默认计划
模式：场景计划
场景持续时间：直到完成
加载行为：同时加载所有Vuser
用户加载并发数量：50/100/150
负载生成器：localhost
思考时间：按录制参数
预期结果：
(1)测试过程中服务器资源占用CPU（均值小于70%），内存（均值小于80%，或者使用期间没有内存泄漏和错误产生），IO-Wait（均值小于10%）（资源占用可根据需要进行调整，或者没有预期，只是测试一个结果，如果测试结果较好就继续加压，测试结果不好就考虑进行优化）
(2)业务成功率目标100%（成功90%，失败10%，各种返回比例满足事先的预期设计比例值）
(3)其他业务需求
OK,还需要一些测试安排计划和测试风险的评估，补充到测试方案里面。一个基本的测试方案基本就可以算是完成了。
并发数
【经典案例1】上班签到系统，早上8点上班，7点半到8点的30分钟的时间里用户会登录签到系统进行签到。公司员工为1000人，平均每个员上登录签到系统的时长为5分钟。可以用下面的方法计算。
C=1000/30*5=166.7
C表示平均并发用户数，那么对这个签到系统每分钟的平均在线用户数为166
系统吞度量要素
一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。
系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间
QPS（TPS）：每秒钟request/事务 数量
并发数： 系统同时处理的request/事务数
响应时间： 一般取平均响应时间
（很多人经常会把并发数和TPS理解混淆）
理解了上面三个要素的意义之后，就能推算出它们之间的关系：
QPS（TPS）= 并发数/平均响应时间 或者 并发数 = QPS*平均响应时间
LoadRunner图表分析
Mercury Loadrunner Analysis中最常用的5种资源
1. Vuser
2. Transactions
3. Web Resources
4. Web Page Breakdown
5. System Resources
在Analysis中选择“Add graph”或“New graph”就可以看到这几个资源了.还有其他没有数据的资源,我们没有让它显示.
如果想查看更多的资源,可以将左下角的display only graphs containing data置为不选.然后选中相应的点“open graph”即可.
打开Analysis首先是Summary Report.显示了测试的分析摘要.下面介绍一下含义：
Duration(持续时间)：了解该测试过程持续时间.测试人员本身要对这个时期内系统一共做了多少的事有大致的熟悉了解.以确定下次增加更多的任务条件下测试的持续时间。
Statistics Summary(统计摘要)：只是大概了解一下测试数据,对我们具体分析没有太大的作用.
Transaction Summary(事务摘要)：了解平均响应时间Average单位为秒. 其余的看不看都可以.都不是很重要.
Analysis summary （场景摘要）
Secenario name 场景名称
Results in session 场景运行的结果目录
Duration 场景运行时间
Statistics summary（场景状态的统计说明）
Maximum running vusers（场景最大用户数）
Total throughput （bytes）（总带宽流量）
Average throughput （bytes/second）（平均每秒宽带流量）
Total hit （总点击数）
Average hits per second （平均每秒点击数）
单击View HTTP Responses summary 选项可以切换到报告最下方HTTP请求的统计
（5worst transaction）5大失败事务的统计
Transaction name （事务名）
Failure ratio[%] （exceeded time/transaction duration）失败率（超标次数/事务持续时间）。该值反映了在所有事务中有百分之多少的事务是无法达到SLA基准值的
Failure value[%](response time /SLA) 失败率（响应时间/SLA） 该值反映了在整个场景运行下，SLA的定义标准值与实际事务值超标的平均百分比，也就是说平均算下来真实的响应时间和定义的阈值误差百分比 最下方列出了平均误差和最大误差
scenario behavior over time（场景行为综述）
在场景中定义的事务在各个时间点上的SLA情况，背景中的X表示在这个时间点上事务没有达到SLA的指标，而上面的application under test error显示了在每个时间段上的错误
transaction summary（事务摘要）
Total passed （事务总通过数）
Total failed （事务的总失败数）
Total stopped （事务的总停止数）
Average response time 可以打开事务平均响应时间图表
Transaction name （事务名）
SLA status （SLA状态）：在SLA的指标测试中最终结果图是通过还是失败
Minimum（事务最小时间）
Average （事务平均时间）
Maximum （事务最大时间）
Std.deviation（标准方差）
90percent（用户感受百分比）这个值说明，采样数据中，有90%的数据比它大，10%的数据比它小（举例，假设有组数据（13465782910）按从小到大的排列后就是（12345678910），在这10个数中第9大的数字是9所以90percent的结果就是9），90percent是可以调整的，在（analysis-View-summary files –transaction percentile）
Service level agreement legend（SLA图标说明）
http responses summary（http响应摘要）
Total http请求返回次数 Per second 每秒请求数
hits per second（每秒点击数）
每秒点击数每一次点击相当于对服务器发出一次请求，一般点击数会随着负载的增加而增加，该数据越大越好。
throughput（带宽使用）
该数据越小说明系统的宽带依赖越小
网络带宽是否足够?
“Throughput”图显示在场景运行期间的每一秒钟，从Web Server 上接受到的数据量的值。 拿这个值和网络带宽比较，可以确定目前的网络带宽是否是瓶颈。
如果该图的曲线随着用户数的增加，没有随着增加，而是呈比较平的直线，说明目前的 网络速度不能够满足目前的系统流量。
transaction summary（事务概要说明）
通过事务数越多说明系统的处理能力越强，失败的事务越少，说明系统越可靠
average transaction response time（每秒事务数）
时间越小说明处理的速度越快，如果和前面的用户负载生成图合并在一起看，就可以发现用户负载增加对系统事务响应时间的影响规律（事务的响应时间也不应该超过用户的最大接受范围，否则会出现系统响应过慢的问题）
Average transaction response time（平均事务响应时间）
TPS也是一个关键的数据，该数据反映了系统在同一时间内能处理业务的最大能力，这个数据越高，说明系统处理能力越强，但是这里的最高值并不一定代表系统的最大处理能力，TPS会受到负载的影响，也会随着负载的增加而逐渐增加，当系统进入繁忙期后，TPS会有所下降
transaction performance summary（事务性能概要）
这里给出了事务的平均时间、最大时间、最小时间，柱状图的落差越小说明响应时间的波动较小，如果落差很大，那么说明系统够稳定
transaction response time under load（在用户负载下事务响应时间）
负载用户增长的过程中响应时间的变化情况，其实这张图也是将uers和average transaction response图做了一个correlate Merge 得到的，该图的线条越平越稳，说明系统越稳定
transaction response time （percentile）（事务响应时间的百分比）
不同百分比下的事务响应时间范围，通过这个图可以了解有多少比例的事务发生在某个时间内，也可以发现响应时间的分布规律，数据月平稳说明响应时间编号越小
Transaction response time （distribution）（每个时间段上的事务数）
该图给出的是每个时间段上的事务数，响应时间较小的分类下的事务数越多越好
看 Transaction Response Time 图，可以判断每个事务完成用的时间，从而可以判断出那个事 务用的时间最长，那些事务用的时间超出预定的可接受时间。
下图可以看出，随着用户数的不断增加，login 事务的响应时间增长的最快！
分析事务的响应时间
第一步，看“Transaction Performance Summary”图，确认那个事务的响应时间比较大， 超出了我们的标准。看下图，login 事务的平均响应时间最长。
然后我们再看“Average Transaction Response Time”，观察login 在整个场景运行中每一 秒的情况。从图中可以看出，login 事务的响应时间并不是一直都比较高，只是随着用户数 的增加，响应时间才明显增加的。
为了定位问题，明白为什么login 事务的响应时间比较长，现在我们要分解login 事务， 分析该页面上每一个元素的性能。在上图中，选择要分解的事务曲线，然后点鼠标右键，选 择“Web Page Breakdown for login”
1. 浏览器向 Web Server 发送请求，一般情况下，该请求首先发送到DNS Server 把DNS 名字解析成IP 地址。解析的过程的时间就是。这个度量时间可以
确定DNS 服务器或者DNS 服务器的配置是否有问题。如果DNS Server 运行情况 比较好，该值会比较小。
2. 解析出 Web Server 的IP 地址后，请求被送到了Web Server，然后浏览器和Web Server 之间需要建立一个初始化连接，建立该连接的过程就是。这个
度量时间可以简单的判断网络情况，也可以判断Web Server 是否能够响应这个请 求。如果正常，该值会比较小。
3. 建立连接后，从Web Server 发出第一个数据包，经过网络传输到客户端，浏览器 成功接受到第一字节的时间就是。这个度量时间不仅可以表示Web Server 的延迟时间，还可以表示出网络的反应时间。
4. 从浏览器接受到第一个字节起，直到成功收到最后一个字节，下载完成止，这段时 间就是。这个度量时间可以判断网络的质量（可以用size/time 比来计算 接受速率）
其他的时间还有 SSL Handshaking（SSL 握手协议，用到该协议的页面比较少）、Client Time（请求在客户端浏览器延迟的时间，可能是由于客户端浏览器的think time 或者客户端 其他方面引起的延迟）、Error Time（从发送了一个HTTP 请求，到Web Server 发送回一个HTTP 错误信息，需要的时间）。
熟悉了以上各个时间的含义后，我们开始看分解页面的图形。
首先看“Downlaod Time Breakdown”，可以看出login 事务分解的各个组件的大小，以 及各个组件的下载时间。
从下图可以看出，login 页面有5 个组件组成，其中next.gif 下载用的时间最长，并且几 乎所有的时间都用在了First Buffer 上，而其大小为1.256KB，并不是很大。
上图提供的组件大小的信息比较简单，更详细的信息参考“Download Component Size Graph”。利用该图可以看出该页面各种组件的大小所占的比例关系。
同样，要看各个组件下载时间的更详细的信息，可以参考“Page Component Breakdown”。 利用该图可以看出该页面各种组件下载时间的比例关系。
选择“Component Breakdown（Over Time）”，可以以图形曲线的形式看出各个组件在场景运行中的每秒钟的下载时间，比较具体。要看到具体的值，可以参考Page Component Breakdown （Over Time）
然后再选择“Download Time BreakDown（Over Time）”，从中可以看出在场景运行中的每一秒钟，组件用在传输的各部分的时间。要看到具体的值，可以参考Page Download Time Breakdown（Over Time）
为了确认问题缘由到底是服务器还是网络，选择“Time to First Buffer Breakdown”，可以看 出Server 时间比network 时间要高的多，从而确定问题是服务器引起的。然后我们就可以参 考Web Server 的相关图表，来确定问题是由服务器的哪个部分引起。遵从这样的步骤，可 以一步步的接近问题源；如果问题由网络引起，可以参考NetWork 相关的图表，确定什么 样的网络问题是性能的瓶颈。同时可以参考“Time To First Buffer BreakDown(Over Time)”
确定WebServer 的问题
网站的性能问题可能是由多种因素引起的，其中大约有一半的性能问题最终归结到Web Server、Web 应用程序和数据库服务器上。采用编程语言（ASP、JSP、ASP.NET 等）的网 站非常依赖于数据库操作，这些都可能是引起性能问题的因素。
最常见的数据库问题是效率比较低的索引设计，数据碎片太多，过时的统计表以及不完 善的应用程序设计。
在 20%的压力测试中，发现Web Server 和Web 应用程序是性能的瓶颈。这些瓶颈主要 是由于服务器配置不当和资源不足。比如，编程比较差的代码以及形成的DLL 能够使用所 有的计算机处理器资源，导致了CPU 的瓶颈。同样，对内存的操作不当和管理不善也很容 易造成内存的瓶颈，所以我们建议在排除其他可能的因素外，首先检查CPU 和物理内存。
比较每次运行的结果
一般情况下，我们进行性能测试的步骤是这样：
1 首先进行一次性能测试，记录下结果，然后分析结果，提出改进的建议
2 开发人员根据建议对代码或者服务器的配置进行修改
3 测试人员在相同的条件下进行第二轮测试
4 测试人员对两轮测试结果比较，确定开发人员修改的结果是否有效 那么在 Analysis 中怎样进行对两轮结果进行比较呢？ 可以采用菜单操作：
然后出现对话框，需要选择需要比较的结果文件(lrr),选择多个
对图表进行组合合并
Analysis 默认的图表都是以时间作为横坐标，然而在分析结果的过程中，我们可能需要以“运 行的用户数”作为横坐标，来比较结果。
假如我们要画出 Windows Resources ——VUsers 的图表，可以这样操作。
首先打开 Windows Resources 图表，然后在图表上点鼠标右键，选择Merge Graphs
出现 Merge Graphs 对话框
选择第一项“Overlay”，出现以下的图表，这样是把两个图表进行了合并，两条曲线的纵轴共用一个原点，横轴还是时间轴。
选择第二项“Title”，出现以下的图表，这样是把两个图表进行了合并，两条曲线的纵轴不 再共用一个原点，VUsers 的原点在Windows Resouces 的上面，横轴还是时间轴。
选择第三项“Correlate”，LoadRunner 提示信息
我们应该这样，打开Running VUsers 图表，在图表上执行前面提到的操作，不过选择第三 项“Correlate”，即可，显示图表如下图
服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等） 注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。
分析集合点
在录制脚本中通常我们会使用到集合点,那么既然我们用到了集合点,我们就需要知道Vuser是在什么时候集合在这个点上,又是怎样的一个被释放的过程.这个时候就需要观察Vuser-Rendezvous图.
图1
可以看到大概在3分50的地方30个用户才全部集中到start集合点,持续了3分多,在7分30的位置开始释放用户,9分30还有18个用户,11分10还有5个用户,整个过程持续了12分.
图2
上面图2是集合点与平均事务响应时间的比较图.
注:在打开analysis之后系统LR默认这两个曲线是不在同一张图中的.这就需要自行设置了.具体步骤如下:
点击图上.右键选择merge graphs.然后在select graph to merge with 中选择即将用来进行比较的graph.如图3:
图3
图2中较深颜色的是平均响应时间,浅色的为集合点,当Vuser在集合点持续了1分后平均响应时间呈现最大值,可见用户的并发对系统的性能是一个很大的考验. 接下来看一下与事务有关的参数分析.下看一张图.
图4
这张图包括Average Transaction Response Time和Running Vuser两个数据图.从图中可以看到Vuser_init_Transaction(系统登录)对系统无任何的影响,Vuser达到15个的时候平均事务响应时间才有明显的升高,也就是说系统达到最优性能的时候允许14个用户同时处理事务,Vuser达到30后1分,系统响应时间最大,那么这个最大响应时间是要推迟1分钟才出现的,在系统稳定之后事务响应时间开始下降说明这个时候有些用户已经执行完了操作.同时也可以看出要想将事务响应时间控制在10S内.Vuser数量最多不能超过2个.看来是很难满足用户的需求了.
做一件事有时候上级会问你这件事办得怎么样了.你会说做完一半了.那么这个一半的事情你花了多少时间呢?所以我们要想知道在给定时间的范围内完成事务的百分比就要靠下面这个图(Transaction Response Time(Percentile)
图中画圈的地方表示10%的事务的响应时间是在80S左右.80S对于用户来说不是一个很小的数字,而且只有10%的事务,汗.你觉得这个系统性能会好么!
实际工作中遇到的事情不是每一件事都能够在很短的时间内完成的,对于那些需要时间的事情我们就要分配适当的时间处理,时间分配的不均匀就会出现有些事情消耗的时间长一些,有些事情消耗的短一些,但我们自己清楚.LR同样也为我们提供了这样的功能,使我们可以了解大部分的事务响应时间是多少?以确定这个系统我们还要付出多少的代价来提高它.
Transaction Response Time(Distribution)-事务响应时间(分布)
显示在方案中执行事务所用时间的分布.如果定义了可以接受的最小和最大事务性能时间,可以通过此图确定服务器性能是否在可接受范围内.
很明显大多数事务的响应时间在60-140S.在我测试过的项目中多数客户所能接受的最大响应时间也要在20S左右.140S的时间!很少有人会去花这么多的时间去等待页面的出现吧!
通过观察以上的数据表.我们不难看到此系统在这种环境下并不理想.世间事有果就有因,那么是什么原因导致得系统性能这样差呢?让我们一步一步的分析.
系统性能不好的原因多方面,我们先从应用程序看.有的时候我不得不承认LR的功能真的很强大,这也是我喜欢它的原因.先看一张页面细分图.
很明显大多数事务的响应时间在60-140S.在我测试过的项目中多数客户所能接受的最大响应时间也要在20S左右.140S的时间!很少有人会去花这么多的时间去等待页面的出现吧!
通过观察以上的数据表.我们不难看到此系统在这种环境下并不理想.世间事有果就有因,那么是什么原因导致得系统性能这样差呢?让我们一步一步的分析.
系统性能不好的原因多方面,我们先从应用程序看.有的时候我不得不承认LR的功能真的很强大,这也是我喜欢它的原因.先看一张页面细分图.
一个应用程序是由很多个组件组成的,整个系统性能不好那我们就把它彻底的剖析一下.图片中显示了整个测试过程中涉及到的所有web页.web page breakdown中显示的是每个页面的下载时间.点选左下角web page breakdown展开,可以看到每个页中包括的css样式表,js脚本,jsp页面等所有的属性. 在select page to breakdown中选择页面. 见图.
在Select Page To Breakdown 中选择http://192.168.0.135:8888/usertasks后,在下方看到属于它的两个组件,第一行中Connection和First Buffer占据了整个的时间,那么它的消耗时间点就在这里,我们解决问题就要从这里下手.
也有可能你的程序中client的时间最长.或者其他的,这些就要根据你自己的测试结果来分析了
CPU,内存.硬盘的瓶颈分析方法
System（系统）
%Total Processor Time
系统中所有处理器都处于繁忙状态的时间百分比，对于多处理器系统来说，该值可以反映所有处理器的平均繁忙状态，该值为100%，如果有一半的处理器为繁忙状态，该值为50%服务器。器消耗的处理器时间数量.如果服务器专用于sql server 可接受的最大上限是80% -85 %.也就是常见的CPU 使用率.
File Data Operations/sec
计算机对文件系统进行读取和写入操作的频率，但是不包括文件控制操作
Process Queue Length
线程在等待分配CPU资源所排队列的长度，此长度不包括正在占有CPU资源的线程。如果该队列的长度大于处理器个数+1，就表示处理器有可能处于阻塞状态（参考值：<=处理器个数+1）
Processor（处理器）
%Processor Time
CPU利用率，可以查看处理器是否处于饱和状态，此值的最佳范围为75%-95%，如果在性能监控过程中此值过低，表示CPU尚未充分利用，还 需要更大的负载压力，如果该值持续超过95%，就表示当前系统的瓶颈为CPU，此时可以考虑增加一个处理器或换一个性能更好的处理器。
%Priviliaged Time
指处理线程执行代码所花时间的百分比。如果该参数值和“physical disk”值一直很高，表明I/O有问题，可考虑采用更快的硬盘系统。
%User Time
指处理器处于用户模式的时间百分比，也就是非内核操作用户进程所耗费的CPU时间。其值可以表示为CPU的数据库操作 （如查找、排序等活动）耗费的时间，如果该值很高，可以考虑增加索引、使用简单的表连接、水平分割大表格等方法来降低该值。
计算机处理器有用户模式和特权模式两种工作方式，用户模式是为应用程序、环境分系统和整数分系统设计的有限处理模式；特权模式是为操作系统组 件设计的，允许其直接访问硬件和所有内存。操作系统将应用程序线程转换成特权模式以访问操作系统服务器。
%DPC Time
指在实例间隔期间，处理器用在延缓程序调用（DPC）接收和提供服务的时间百分比，就是消耗在网络处理上的时间，该值越低越好。由于DPC是以特权模式执行的，DPC时间的百分比为特权时间百分比的一部分。
ProcessorQueue Length
简述：判断CPU瓶颈,如果processor queue length显示的队列长度保持不变(>=2)并且处理器的利用率%Processor time超过90%,那么很可能存在处理器瓶颈.如果发现processor queue length显示的队列长度超过2,而处理器的利用率却一直很低,或许更应该去解决处理器阻塞问题,这里处理器一般不是瓶颈.
参考值：
interrupt/sec
简述：指处理器接收并维护硬件中断的平均值，单位是事件数/秒，这 个值说明了能够产生中断的设备（如系统时钟、鼠标、磁盘驱动器、网卡和其他外部设备）的活动情况，这些可以产生中断 的设备通常在完成了一项任务时中断处理器。
%interrupte time
简述：处理器在实例间隔期间接受和服务硬件中断的时间。此 值间接表示了产生中断的设备的活动，如系统时钟、鼠标、磁盘驱动器、网卡和其他外部设备，这些设备通常会中断处理器。
Queue Length
简述:指跟踪服务器工作队列当前长度的计数器，该数值会显示出处理器瓶颈。队列长度持续大于2则表示可能出现处 理器拥塞。
Memory（内存）
Page Faults/sec
当处理器在内存中读取某一页出现错误时，就会产生缺页中断，也就是 page Fault。如果这个页位于内存的其他位置，这种错误称为软错误，用Transition Fault/sec 来衡量；如果这个页位于硬盘上，必须从硬盘重新读取，这个错误成为硬错误。硬错误会使系统的运行效率很快将下来。Page Faults/sec这个计数器就表示每秒钟处理的错误页数，包括硬错误和软错误。
Page Input/sec
简述：为了解决硬错误页，从磁盘上读取的页数。（参考值：>=Page Reads/sec）
Page Reads/sec
简述：为了解决硬错误页，从磁盘上读取的次数。解析对内存的引用，必须读取页文件的次数。阈值为>5.越低越好。大数值表示磁盘读而不是缓存读。
Page/sec
表示为了解决硬错误而从硬盘上读取或写入硬盘的页数（参考值：00~20）
一般如果Page/sec持续高于几百，那么您应该进一步研究页交换活动。有可能需要增加内存，以减少换页的需求（你可以把这个数字乘以4k就得到由此引起的硬盘数据流量）。Pages/sec的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所致。
参考值：
Page Fault
简述：处理器每秒处理的错误页（包括软/硬错误）。当处理器向内存指定的位置请求一页（可能是数据或代码）出现错误时，这就构成一个Page Fault。如果该页在内存的其他位置，该错误被称为软错误（用Transition Fault/sec记数器衡量）；如果该页必须从硬盘上重新读取时，被称为硬错误。许多处理器可以在有大量软错误的情况下继续操作。但是，硬错误可以导致明显的拖延。
参考值：
Pages per second
每秒钟检索的页数。该数字应少于每秒一页Working set:理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。
Available Mbytes
剩余的可用物理内存，单位是兆字节（参考值：>=10%）用物理内存数. 如果Available Mbytes的值很小(4 MB 或更小)，则说明计算机上总的内存可能不足，或某程序没有释放内存。
参考值：4 MB或更小，至少要有10%的物理内存值
Cathe Bytes
文件系统的缓存（默认为50%的可用物理内存）如IIS5.0运行内存不够时，它会自动整理缓存。需要关注该计数器的趋势变化。该指标只显示最后一次观察的值，它不是一个平均值。
pool paged bytes
简述: 指在分页池中的字节 数，分页池是系统内存中可供对象使用的一个区域。
pool nonpaged bytes
简述:指非分页池中的 字节数，非分页池中的字节数如果持续增加表示可能存在内存泄漏问题，需要进一步结合其他指标，来判断是否存在严重的内存泄漏还是其他原因引起的非分页池增加。
Process（进程）
private Bytes
进程无法与其他进程共享的字节数量。该计数器的值较大时，有可能是内存泄露的信号
Work set
最近处理线程使用的内存页
Page Faults/sec
简述：将进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。指每秒钟出错页面的平均数量。
参考值：
Private Bytes
简述：此进程所分配的无法与其它进程共享的当前字节数量。如果系统性能随着时间而降低，则此计数器可以是内存泄漏的最佳指示器。
参考值：
Work set
简述：处理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。
参考值：
PhysicalDisk（磁盘）
%Disk Time
表示磁盘驱动器为读取或写入请求提供服务所用的时间百分比，如果只有%Disk Time比较大，硬盘有可能是瓶颈。指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大，那么硬盘不是瓶颈。如果只有%Disk Time比较大，另外两个都比较适中，硬盘可能会是瓶颈。在记录该计数器之前，请在Windows 2000 的命令行窗口中运行diskperf -yD。若数值持续超过80%，则可能是内存泄漏。应当总小于90%
Average Disk Queue Length
表示磁盘读取和写入请求提供服务所用的时间百分比，可以通过增加磁盘构造磁盘阵列来提高性能（<=磁盘数的2倍）读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2 倍。要提高性能，可增加磁盘。注意：一个Raid Disk实际有多个磁盘。不应当超过物理磁盘数量的2倍,正常值<0.5
Average Disk Read Queue Length
表示磁盘读取请求的平均数
Average Disk write Queue Length
表示磁盘写入请求的平均数
Average Disk sec/Read
磁盘中读取数据的平均时间，单位是秒
Average Disk sec/Transer
磁盘中写入数据的平均时间，单位是秒，一般来说，定义该值小于15ms最为优异，介于15-30ms之间为良好，30-60ms之间为可以接受，超过60ms则需要考虑更换硬盘或硬盘的RAID方式了
%Disk reads/sec(physicaldisk_total)
每秒读硬盘字节数. 该指标应总小于磁盘I/O子系统的容量
%Disk write/sec(physicaldisk_total)
每秒写硬盘字节数. 该指标应当总小于硬盘I/O子系统的容量
Disk Bytes/sec
指在进行写入或读取操作时从磁盘上传送或传出的字节速率。
此值取决于硬盘的速度
Disk Transfers/sec
指在此盘上读取/写入操作速率。
正常值<(Disk Bytes/sec)/3，此值过大表示系统要求的IO速度已接近硬盘的最大速度，要更换更快的硬盘 D
CurrentDiskQueueLength
简述：读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。(磁盘数1.5-2倍)
Network Interface（网络）
Byte Total/sec
表示网络中接受和发送字节的速度，可以用该计数器来判断网络是否存在瓶颈（参考值：该计数器和网络带宽相除，<50%）。以b为单位转化为M需要除以1024再除1024.
LoadRunner分析资源占用率
1. 平均事务响应时间 Average Transation Response Time 优秀：<2s 良好：2-5s 及格：6-10s 不及格：>10s
2. 每秒点击率 Hits per Second
当增大系统的压力(或增加并发用户数)时，吞吐率和TPS的变化曲线呈大体一致，则系统基本稳定若压力增大时，吞吐率的曲线增加到一定程度后出现变化缓慢，甚至平坦，很可能是网络出现带宽瓶颈.同理若点击率/TPS曲线出现变化缓慢或者平坦,说明服务器开始出现.
3. 请求响应时间 Time to Last Byte
4. 每秒系统处理事务数 Transaction per second
5. 吞吐量 Throughout
6. CPU利用率
Processor / %Processor Time 好：70% 坏：85% 很差：90%+
7. 数据库操作消耗的CPU时间
Processor / %User Time 如果该值较大，可以考虑是否能通过友好算法等方法降低这个值。如果该服务器是数据库服务器， Processor\%User Time 值大的原因很可能是数据库的排序或是函数操作消耗了过多的CPU时间，此时可以考虑对数据库系统进行优化。
8. 核心态CPU平均利用率
Processor /%Privileged Time 如果该参数值和"Physical Disk"参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统
9. 处理列队中的线程数
Processor / Processor Queue Length 如果该值保持不变(>=2)个并
且%Processor Time 超过90%，那么可能存在处理器瓶颈。如果发现超过2，而处理器的利用率却一直很低，那么或许更应该去解决处理器阻塞问题，这里处理器一般不是瓶颈。
10. 文件系统缓存 Memory / Cache Bytes 50%的可用物理内存
11. 剩余的可用内存 Memory / Avaiable Mbytes 至少要有10% 的物理内存值
12. 每秒下载页数 Memory / pages/sec 好：无页交换 坏：CPU每秒10个页交换 很差：更多的页交换
13. 页面读取操作速率 Memory / page read/sec 如果页面读取操作速率很低，同时 % Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。
14. 物理磁盘利用率 Physical Disk / %Disk Time 好：<30% 坏：<40% 很差：<50%+
15. 物理磁盘平均磁盘I/O队列长度
Physical Disk / Avg.Disk Queue Length 该值应不超过磁盘数的1.5~2 倍。要提高性能，可增加磁盘
16. 网络吞吐量 Network Interface / Bytes Total/sec 判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽，结果应该小于50%
17. 数据高速缓存区命中率 命中率应大于0.90最好
18. 共享区库缓存区命中率 命中率应大于0.99
19. 监控 SGA 中字典缓冲区的命中率 命中率应大于0.85
20. 检测回滚段的争用 小于1%
21. 监控 SGA 中重做日志缓存区的命中率 应该小于1%
22. 监控内存和硬盘的排序比率 最好使它小于 10%
性能问题分析
- 1、网络瓶颈，如带宽，流量等形成的网络环境
- 2、应用服务瓶颈，如中间件的基本配置，CACHE等
- 3、系统瓶颈，这个比较常用：应用服务器，数据库服务器以及客户机的CPU，内存，硬盘等配置
- 4、数据库瓶颈，以ORACLE为例，SYS中默认的一些参数设置
- 5、应用程序本身瓶颈，
针对网络瓶颈，现在冒似很少，不过也不是没有，首先想一下如果有网络的阻塞，断网，带宽被其他资源占用，限速等情况，应用程序或系统会是什么情况，针对WEB，无非是超时，HTTP400，500之类的错，针对一些客户端程序，可能也是超时，掉线，服务器下发的，需要服务器返回的信息获取不到还有一种更明显的情况，应该就是事务提交慢，如果封装事务的代码再不完善，一般造成的错误，无非就是数据提交不完整，或者因为网终原因+代码缺陷造成重复性提交。如此综合下来，肯定是考虑网络有瓶颈，然后考虑网络有问题时，怎样去优化，是需要优化交互的一些代码，还是接口之类的。
应用服务的瓶颈的定位，比较复杂，学习中，不过网上有很多资料可以参考的。一般像tomcat，weblogic之类的，有默认的设置，也有经过架构和维护人员进行试验调试的一些值，这些值一般可以满足程序发布的需要，不必进行太多的设置，可能我们认识的最基本的就是JAVA_OPTS的设置，maxThreads，time_out之类的参数我们做借助LR，Jemeter或webload之类的工具，执行性能测试，尤其是对应用服务造成了压力，如果应用服务有瓶颈，一般我们设置的log4j.properties，日志都会记录下来。然后根据日志，去进一步确定应用服务的问题
系统瓶颈，这个定位虽说比较复杂，但是有很多前辈的经验值参考，不作说明，相信用LR的同行，也可以从性能记数器中得出一些指标值，加上nagios，cacti，可以很明显的看出系统哪些资源够用，哪些资源明显不够用。不过，一般系统瓶颈的造成，是因为应用程序本身造成的。关于这点儿的分析和定位，就需要归入应用程序本身瓶颈分析和定位了。
现在基本所有的东东，都离不开数据库这个后台，数据库的瓶颈实在是不知道是什么概念，数据库管理员的工作，数据库管理员日常做的工作，可能就是有瓶颈定位的工作，比如：查询一下V$sys_event，V$sysstat，v$syssql之类的表，比对一下日常正常情况下的监控数据，看一下有没有异常等。其他方面，我也不是太了解。
应用程序瓶颈，这个是测试过程中最需要去关注的，需要测试人员和开发人员配合执行，然后定位，我这儿做的大都是执行性的，比如会有脚本去运行，开发人员会结合jprofiler之类的工具，去看一下堆遍历，线程剖析的情况确定哪儿有问题。大致是这样，没有实际操作过
逐步细化分析，先可以监控一些常见衡量CPU，内存，磁盘的性能指标，进行综合分析，然后根据所测系统具体情况，进行初步问题定位，然后确定更详细的监控指标来分析。
怀疑内存不足时
方法1：
【监控指标】：Memory Available MBytes ，Memory的Pages/sec， page read/sec， Page Faults/sec
【参考值】：
如果 Page Reads/Sec 比率持续保持为 5，表示可能内存不足。
Page/sec 推荐00-20（如果服务器没有足够的内存处理其工作负荷，此数值将一直很高。如果大于80，表示有问题）。
方法2：根据Physical Disk 值分析性能瓶颈
【监控指标】：Memory Available MBytes ，Pages read/sec，%Disk Time 和 Avg.Disk Queue Length
【参考值】：%Disk Time建议阈值90%
当内存不足时，有点进程会转移到硬盘上去运行，造成性能急剧下降，而且一个缺少内存的系统常常表现出很高的CPU利用率，因为它需要不断的扫描内存，将内存中的页面移到硬盘上。
怀疑内存泄漏时
【监控指标】：Memory Available MBytes ，Process\Private Bytes和Process\Working Set，PhysicalDisk/%Disk Time
【说明】：
Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。内存泄漏应该通过一个长时间的，用来研究分析当所有内存都耗尽时，应用程序反应情况的测试来检验。
CPU分析
【监控指标】：
System %Processor Time CPU，Processor %Processor Time CPU
Processor%user time 和Processor%Privileged Time
system\Processor Queue Length
Context Switches/sec 和%Privileged Time
【参考值】：
System\%Total processor time不持续超过90%，如果服务器专用于SQL Server，可接受的最大上限是80-85% ，合理使用的范围在60%至70%。
Processor %Processor Time小于75%
system\Processor Queue Length值，小于CPU数量的总数+1
CPU瓶颈问题
1、System\%Total processor time如果该值持续超过90%，且processor queue length显示的队列长度保持不变(>=2)，则说明整个系统面临着处理器方面的瓶颈.
注：在某些多CPU系统中，该数据虽然本身并不大，但CPU之间的负载状况极不均衡，此时也应该视作系统产生了处理器方面的瓶颈.
2、排除内存因素，如果Processor %Processor Time计数器的值比较大，而同时网卡和硬盘的值比较低，那么可以确定CPU 瓶颈。（内存不足时，有点进程会转移到硬盘上去运行，造成性能急剧下降，而且一个缺少内存的系统常常表现出很高的CPU利用率，因为它需要不断的扫描内存，将内存中的页面移到硬盘上。）
造成高CPU使用率的原因：
频繁执行程序，复杂运算操作，消耗CPU严重
数据库查询语句复杂，大量的 where 子句，order by， group by 排序等，CPU容易出现瓶颈
内存不足，IO磁盘问题使得CPU的开销增加
磁盘I/O分析
【监控指标】：PhysicalDisk/%Disk time，PhysicalDisk/%Idle Time，Physical Disk\ Avg.Disk Queue Length， Disk sec/Transfer
【参考值】：%Disk Time建议阈值90%
Windows资源监控中，如果% Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。
Processor%Privileged Time该参数值一直很高，且如果在 Physical Disk 计数器中，只有%Disk time 比较大，其他值都比较适中，硬盘可能会是瓶颈。若几个值都比较大， 那么硬盘不是瓶颈。若数值持续超过80%，则可能是内存泄露。如果 Physical Disk 计数器的值很高时该计数器的值（Processor%Privileged Time）也一直很高， 则考虑使用速度更快或效率更高的磁盘子系统。
Disk sec/Transfer 一般来说，该数值小于15ms为最好，介于15-30ms之间为良好，30-60ms之间为可以接受，超过60ms则需要考虑更换硬盘或是硬盘的RAID方式了.
Average Transaciton Response Time（事务平均响应时间）随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势
Transactions per Second（每秒通过事务数/TPS）当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈
Hits per Second（每秒点击次数）通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。
Throughput（吞吐率）可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。
Connections（连接数）当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）
Time to First Buffer Breakdown（Over Time）（第一次缓冲时间细分（随时间变化））可以使用该图确定场景或会话步骤运行期间服务器或网络出现问题的时间。
硬件问题
请观察 Processor\ Interrupts/sec 计数器的值，该计数器测量来自输入/输出 (I/O) 设备的服务请求的速度。如果此计数器的值明显增加，而系统活动没有相应增加，则表明存在硬件问题。
判断应用程序的问题
如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换(context switches/sec显示的上下文切换次数太高)那么就会占用大量的系统资源,如果系统的吞吐量降低并且CPU的使用率很高,并且此现象发生时切换水平在15000以上,那么意味着上下文切换次数过高。
从图的整体看.context switches/sec变化不大,throughout曲线的斜率较高,并且此时的context switches/sec已经超过了15000.程序还是需要进一步优化。
I/O资源成为系统性能的瓶颈的征兆
IO Data Bytes/sec(处理从I/O操作读取/写入字节的速度。这个计数器为所有由本处理产生的包括文件、网络和设备I/O的活动计数。)
IO Data Operations/sec
IO Other Bytes/sec
IO Other Operations/sec
IO Read Bytes/sec(每秒IO读取字节数)
IO Read Operations/sec
IO Write Bytes/sec(每秒IO写出字节数)
IO Write Operations/sec
过高的磁盘利用率(high disk utilization)
太长的磁盘等待队列(Physical Disk\ Current Disk Queue Length,正在等待磁盘访问的系统请求数量)
等待磁盘I/O的时间所占的百分率太高(Average Disk Queue Length)
太高的物理I/O速率:large physical I/O rate(not sufficient in itself)
过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))
太长的运行进程队列，但CPU却空闲(Process Queue Length)
在运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数
监视磁盘的使用情况
监视磁盘活动涉及两个主要方面：
监视磁盘 I/O 及检测过度换页
隔离 SQL Server 产生的磁盘活动
监视磁盘 I/O 及检测过度换页
可以对下面两个计数器进行监视以确定磁盘活动：
PhysicalDisk: % Disk Time
PhysicalDisk: Avg. Disk Queue Length
在系统监视器中，PhysicalDisk: % Disk Time 计数器监视磁盘忙于读/写活动所用时间的百分比。如果 PhysicalDisk: % Disk Time 计数器的值较高（大于 90%），请检查PhysicalDisk: Current Disk Queue Length 计数器了解等待进行磁盘访问的系统请求数量。等待 I/O 请求的数量应该保持在不超过组成物理磁盘的轴数的 1.5 到 2 倍。大多数磁盘只有一个轴，但独立磁盘冗余阵列 (RAID) 设备通常有多个轴。硬件 RAID 设备在系统监视器中显示为一个物理磁盘。通过软件创建的多个RAID 设备在系统监视器中显示为多个实例。
可以使用 Current Disk Queue Length 和 % Disk Time 计数器的值检测磁盘子系统中的瓶颈。如果 Current Disk Queue Length 和 % Disk Time 计数器的值一直很高，则考虑下列事项：
使用速度更快的磁盘驱动器。
将某些文件移至其他磁盘或服务器。
如果正在使用一个 RAID 阵列，则在该阵列中添加磁盘。
如果使用 RAID 设备，% Disk Time 计数器会指示大于 100% 的值。如果出现这种情况，则使用 PhysicalDisk: Avg.Disk Queue Length 计数器来确定等待进行磁盘访问的平均系统请求数量。
I/O 依赖的应用程序或系统可能会使磁盘持续处于活动状态。
监视 Memory: Page Faults/sec 计数器可以确保磁盘活动不是由分页导致的。在 Windows 中，换页的原因包括：
配置进程占用了过多内存。
文件系统活动。
如果在同一硬盘上有多个逻辑分区，请使用 Logical Disk 计数器而非 Physical Disk 计数器。查看逻辑磁盘计数器有助于确定哪些文件被频繁访问。当发现磁盘有大量读/写活动时，请查看读写专用计数器以确定导致每个逻辑卷负荷增加的磁盘活动类型，例如，Logical Disk: Disk Write Bytes/sec。
判断磁盘瓶颈
%Disk Time和Avg.Disk Queue Length的值 (应不大于组成物理磁盘的主轴数的 1.5 到2倍) 很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。
Physical Disk\ Disk Reads/sec and Disk Writes/sec 大于20 ms,则有可能磁盘瓶颈
Physical Disk\ Current Disk Queue Length
Physical Disk\ % Disk Time
LogicalDisk\ % Free Space
测试磁盘性能时，将性能数据记录到另一个磁盘或计算机，以便这些数据不会干扰您正在测试的磁盘。
可能需要观察的附加计数器包括 Physical Disk\ Avg.Disk sec/Transfer 、Avg.DiskBytes/Transfer，和Disk Bytes/sec。
Avg.Disk sec/Transfer 计数器反映磁盘完成请求所用的时间。较高的值表明磁盘控制器由于失败而不断重试该磁盘。这些故障会增加平均磁盘传送时间。对于大多数磁盘，较高的磁盘平均传送时间是大于 0.3 秒。盘中写入数据的平均时间，单位是秒，一般来说，定义该值小于15ms最为优异，介于15-30ms之间为良好，30-60ms之间为可以接受，超过60ms则需要考虑更换硬盘或硬盘的RAID方式了。
也可以查看 Avg.Disk Bytes/Transfer 的值。值大于 20 KB 表示该磁盘驱动器通常运行良好;如果应用程序正在访问磁盘，则会产生较低的值。例如，随机访问磁盘的应用程序会增加平均 Disk sec/Transfer 时间，因为随机传送需要增加搜索时间。
Disk Transfers/sec 指在此盘上读取/写入操作速率。正常值<(Disk Bytes/sec)/3，此值过大表示系统要求的IO速度已接近硬盘的最大速度，要更换更快的硬盘。
备注：如果使用 RAID 设备，% Disk Time 计数器会指示大于 100% 的值。
Disk Bytes/sec 提供磁盘系统的吞吐率
决定工作负载的平衡要平衡网络服务器上的负载，需要了解服务器磁盘驱动器的繁忙程度。使用 Physical Disk\ %Disk Time 计数器，该计数器显示驱动器活动时间的百分比。如果 % Disk Time 较高(超过90%)，请检查 Physical Disk\ Current Disk Queue Length 计数器以查看正在等待磁盘访问的系统请求数量。等待 I/O 请求的数量应当保持在不大于组成物理磁盘的主轴数的 1.5 到2倍。
尽管廉价磁盘冗余阵列 (RAID) 设备通常有多个主轴，大多数磁盘有一个主轴。硬件 RAID设备在“系统监视器”中显示为一个物理磁盘;通过软件创建的 RAID 设备显示为多个驱动器(实例)。可以监视每个物理驱动器(而不是 RAID)的 Physical Disk 计数器，也可以使用 _Total 实例来监视所有计算机驱动器的数据。
使用 Current Disk Queue Length 和 % Disk Time 计数器来检测磁盘子系统的瓶颈。如果Current Disk Queue Length 和 % Disk Time 的值始终较高，可以考虑升级磁盘驱动器或将某些文件移动到其他磁盘或服务器。
判断磁盘瓶颈的方法通过以下公式来计算：
每磁盘的I/O数=[读次数+（4*写次数）]/磁盘个数
如果计算出的每磁盘的I/O数大于磁盘的处理能力，那么磁盘存在瓶颈。
碰到过的性能问题
- 1. 在高并发的情况下，产生的处理失败（比如：数据库连接池过低，服务器连接数超过上限，数据库锁控制考虑不足等）
- 2. 内存泄露（比如：在长时间运行下，内存没有正常释放，发生宕机等）
- 3. CPU使用偏离（比如：高并发导致CPU使用率过高）
- 4. 日志打印过多，服务器无硬盘空间
如何定位这些性能问题
1. 查看系统日志，日志是定位问题的不二法宝，如果日志记录的全面，很容易通过日志发现问题。
比如，系统宕机时，系统日志打印了某方法执行时抛出out of memory的错误，我们就可以顺藤摸瓜，很快定位到导致内存溢出的问题在哪里。
2. 利用性能监控工具，比如：JAVA开发B/S结构的项目，可以通过JDK自带的Jconsole，或者JProfiler，来监控服务器性能，Jconsole可以远程监控服务器的CPU，内存，线程等状态，并绘制变化曲线图。
利用Spotlight可以监控数据库使用情况。
我们需要关注的性能点有：CPU负载，内存使用率，网络I/O等
3. 工具和日志只是手段，除此之外，还需要设计合理的性能测试场景
具体场景有：性能测试，负载测试，压力测试，稳定性测试，浪涌测试等
好的测试场景，能更加快速的发现瓶颈，定位瓶颈
4. 了解系统参数配置，可以进行后期的性能调优
5. 请求无响应，浏览器始终处于等待状态。
定位方法：kill -3或者jstack先分析线程堆栈，找到当前block的线程。
常见于：外部接口调用无返回或者网络IO阻塞无响应；死锁；死循环；……。
6. 宕机，进程挂掉。
定位方法（这一类问题普遍比较难定位）：
（1）寻找hs_err_pidxxx.log这样的JVM日志
（2）使用JVM参数在JVM crash时写入到dump文件中
（3）catalina.out中寻找最后的日志
（4）宕机前环境数据采集
常见于：JDK bug（数次遇到过JIT引起的这一类问题）；调用dll的问题；……
7.请求响应时间长。
定位方法：kill -3或者jstack先分析线程堆栈，看线程大都停留在什么操作上面，再细化分析。
常见于： 内存不足，可见到连续的Full GC；网络拥塞；LoadRunner等压力客户端瓶颈；数据库瓶颈，可进一步分析DB快照；……
8. TPS低；TPS逐渐降低；TPS振荡幅度过大。
定位方法（这一类问题最常见，定位的方法也最复杂）：
首先观察在压力增大时，CPU使用率能否上去，如果不能上去，寻找其他瓶颈：网络/内存/磁盘/……；CPU
使用率上去了，观察在无压力时，是否有背景CPU使用（例如有后台定时任务线程消耗了大量CPU资源），如果没有，那可以尝试JProfiler等工具结合线程分析、业务分析，寻找热点。
常见于：其他业务线程干扰；内存泄露；连接句柄用完；缓存命中率低下……
线程分析
kill -3 pid获取到目前jvm的线程堆栈信息，特别需要关注的是wait for monitor这样的线程，这种线程是指在等待锁的线程，等待一两分钟后再次kill -3 pid，看看这些wait for monitor的线程的变化情况，对于分析线程中是否存在不合理的竞争过高的锁的分析是非常重要的。
