性能说明
说明：文章转自http://blog.csdn.net/lifetragedy/article/details/7707455，如侵版权，请联系我，我会及时处理。
一、从性能谈起
1.1性能测试简介
即压力测试，就是根据一定数量的VU（Virtual Users）我称为并发用户操作核心交易后，系统所能达到的最大瓶劲，以便于发现系统的极限、有没有Outof memory这样的问题存在以及相关的系统设置、配置是否搭挡的合理的一种测试。
一般商业的比较好的用LoaderRunner，如果没钱的就用Opensource的Jmeter来模拟这个VU的操作。
压力测试，存在几个误区，需要小心。
1） 无限大的拼命增加VU的数量
系统再完美，硬件配置再高，也经不住没有经过合理运算的VU的压力呀。
2） 偏执的用一定的数据量的VU，跑7*24小时
不是说这个没必要，很有必要，小日本的电视为什么寿命敢说比中国人生产的电视机寿命长？因为它用一个机械臂就对着电视机的按钮不断的点点点。
我们说的压力测试要测试多长时间，关键是要看经过科学计算的VU的数量以及核心交易数有多少，不是说我拿250个VU跑24*7如果没有问题我这个系统就没有问题了，这样的说法是不对的，错误的。随便举个例子就能把你推倒。
假设我有250个VU，同时跑上万笔交易，每个VU都有上万笔交易，250个VU一次跑下来可能就要数个小时，你又怎么能断定250个VU对于这样的系统我跑24*7小时就能真的达到上万笔交易在250个VU的并发操作下能够真的跑完7天的全部交易？可能需要一周半或者两周呢？对吧？
我还看到过有人拿500个VU对着一条交易反复跑24*7小时。。。这样的测试有意义吗？你系统就仅仅只有一条交易？你怎么能够判断这条交易涉及到的数据量最大？更不用说交易是彼此间有依赖的，可能a+b+c+d的交易的一个混合组织就能够超出你单笔交易所涉及到的数据量了呢！
1.2合理的制定系统最大用户、并发用户
提供下面这个公式，以供大家在平时或者日常需要进行的性能测试中作为一个参考。
（1） 计算平均的并发用户数：C = nL/T
公式（1）中，C是平均的并发用户数；n是login session的数量；L是login session的平均长度；T指考察的时间段长度。
（2） 并发用户数峰值：C’ ≈ C+3根号C
公式（2）则给出了并发用户数峰值的计算方式中，其中，C’指并发用户数的峰值，C就是公式（1）中得到的平均的并发用户数。该公式的得出是假设用户的loginsession产生符合泊松分布而估算得到的。
实例：
假设有一个OA系统，该系统有3000个用户，平均每天大约有400个用户要访问该系统，对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为4小时，在一天的时间内，用户只在8小时内使用该系统。
则根据公式（1）和公式（2），可以得到：
C = 400*4/8 = 200
C’≈200+3*根号200 = 242
F=VU * R / T
其中F为吞吐量，VU表示虚拟用户个数，R表示每个虚拟用户发出的请求数，T表示性能测试所用的时间
R = T / TS。
1.3影响和评估性能的几个关键指标
从上面的公式一节中我们还得到了一个名词“吐吞量”。和吞吐量相关的有下面这些概念，记录下来以供参考。
² 吞吐量
指在一次性能测试过程中网络上传输的数据量的总和。
对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，在容量规划的测试中，吞吐量是一个重点关注的指标，因为它能够说明系统级别的负载能力，另外，在性能调优过程中，吞吐量指标也有重要的价值。
² 吞吐率
单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量。它是衡量网络性能的重要指标，通常情况下，吞吐率用“字节数/秒”来衡量，当然，你可以用“请求数/秒”和“页面数/秒”来衡量。其实，不管是一个请求还是一个页面，它的本质都是在网络上传输的数据，那么来表示数据的单位就是字节数。
² 事务
就是用户某一步或几步操作的集合。不过，我们要保证它有一个完整意义。比如用户对某一个页面的一次请求，用户对某系统的一次登录，淘宝用户对商品的一次确认支付过程。这些我们都可以看作一个事务。那么如何衡量服务器对事务的处理能力。又引出一个概念----TPS
² TPS (Transaction Per second)
每秒钟系统能够处理事务或交易的数量，它是衡量系统处理能力的重要指标。
² 点击率（Hit Per Second）
点击率可以看做是TPS的一种特定情况。点击率更能体现用户端对服务器的压力。TPS更能体现服务器对客户请求的处理能力。
每秒钟用户向web服务器提交的HTTP请求数。这个指标是web 应用特有的一个指标；web应用是“请求-响应”模式，用户发一个申请，服务器就要处理一次，所以点击是web应用能够处理的交易的最小单位。如果把每次点击定义为一个交易，点击率和TPS就是一个概念。容易看出，点击率越大。对服务器的压力也越大，点击率只是一个性能参考指标，重要的是分析点击时产生的影响。
需要注意的是，这里的点击不是指鼠标的一次“单击”操作，因为一次“单击”操作中，客户端可能向服务器发现多个HTTP请求。
² 吞吐量指标的作用：
ü 用户协助设计性能测试场景，以及衡量性能测试场景是否达到了预期的设计目标：在设计性能测试场景时，吞吐量可被用户协助设计性能测试场景，根据估算的吞吐量数据，可以对应到测试场景的事务发生频率，事务发生次数等；另外，在测试完成后，根据实际的吞吐量可以衡量测试是否达到了预期的目标。
ü 用于协助分析性能瓶颈：吞吐量的限制是性能瓶颈的一种重要表现形式，因此，有针对性地对吞吐量设计测试，可以协助尽快定位到性能冰晶所在位置。
² 平均相应时间
也称为系统响应时间，它一般指在指定数量的VU情况下，每笔交易从mouse 的click到IE的数据刷新与展示之间的间隔，比如说：250个VU下每笔交易的响应时间不超过2秒。
当然，响应时间也不能一概而论，对于实时交易如果银行柜台操作、超市收银员（邪恶的笑。。。）的操作、证交所交易员的操作来说这些操作的响应时间当然是越快越好，而对于一些企业级的如：
与银行T+1交易间的数据跑批、延时交易、T+1报表等，你要求它在2秒内响应，它也做不到啊。就好比你有个1MB的带宽，你传的东西是超过4MB，你要它在2秒内跑完理论速度也做不到啊，对吧，所以有些报表或者数据，光前面传输时间就不止两秒了。。。一口咬死说我所有的交易平均相应时间要2秒，真的是不科学的！
1.4 合理的性能测试
² VU数量的增加
一个合理的性能测试除了需要合理的计算VU的数量、合理的设置系统平均响应时间外还需要合理的在测试时去规划发起VU的时间，比如说，我看到有人喜欢这样做压力测试。
第一秒时间，500个并发用户全部发起了。。。结果导致系统没多久就崩了，然后说系统没有满足设计要求。
为什么说上述这样的做法是不对的？我们说不是完全不对，只能说这样的测试已经超过了500个VU的并发的设计指标了。
合理的并发应该是如下这样的：
有25-50个VU开始起交易了，然后过一段时间又有25-50个用户，过一段时间又增加一些VU，当所有的设计VU都发起交易了，此时，再让压力测试跑一段时间比如说：24*7是比较合理的。所以VU数量不是一上手就500个在一秒内发起的，VU数量的增加应该如下面这张趋势图：
这是一个阶梯状的梯型图，可以看到VU的发起是逐渐逐渐增多的，以下两种情况如果发生需要检查你的系统是否在原有设置上存在问题：
ü VU数量上升阶段时崩溃
有时仅仅在VU数量上升阶段，系统就会了现各种各样的错误，甚至有崩溃者，这时就有重新考虑你的系统是否有设置不合理的地方了。
ü VU全部发起后没多久系统崩溃
VU在达到最高值时即所有的VU都已经发起了，此时它是以一条直的水平线随着系统运行而向前延伸着的，但过不了多久，比如说：运行24*7小时，运行了没一、两天，系统崩溃了，也需要做检查。
所以，理想的性能测试应该是VU数量上升到最终VU从发起开始到最后所有VU把交易做完后，VU数量落回零为止。² 吐吞量的变化
从2.3节我们可以知道，吞吐量是随着压力/性能测试的时间而逐渐增大的，因此你的吞吐量指示应该如下图所示：
肯定是这样，你的吞吐量因该是积累的，如果你的吞吐量在上升了一段时间后突然下落，而此时你的性能测试还在跑着，如下图所示：
那么，此时代表什么事情发生了？你可以查一下你的loaderrunner或者jmeter里对于这段吞吐量回落期间的交易的response的状态进行查看，你将会发现大量的error已经产生，因为产生了error，所以你的交易其实已经出错了，因此每次运行的数据量越来越小，这也就意味着你的压力测试没有过关，系统被你压崩了！
² 平均响应时间
平均响应时间如VU的数量增加趋势图一样，一定是一开始响应时间最短，然后一点点增高，当增高到一定的程度后，即所有的VU都发起交易时，你的响应时间应该维持在一个水平值，然后随着VU将交易都一笔笔做完后，这个响应时间就会落下来，这段时间内的平均值就是你的系统平均响应时间。看看它，有没有符合设计标准？
² 内存监控
我们就来说AppServer，我们这边用的是Tomcat即SUN的JVM的内存变化，我们就用两张图例来讲解吧：
理想状态情况下的JVM内存使用趋势：
这是一个波浪型的（或者也可以说是锯齿型的）趋势图，随着VU数量的一点点增加，我们的内存使用数会不断的增加，但是JVM的垃圾回收是自动回收机制的，因此如果你的JVM如上述样的趋势，内存上涨一段时间，随即会一点点下落，然后再上涨一点，涨到快到头了又开始下落，直到最后你的VU数量全部下降下来时，你的JVM的内存使用也会一点点的下降。
非理想状态情况下的JVM内存使用趋势：
嘿嘿嘿，看到了吗？你的JVM随着VU 数量的上升，而直线上升，然后到了一定的点后，即到了java –Xmx后的那个值后，突然直线回落，而此时你的交易还在进行，压力测试也还在进行，可是内存突然回落了。。。因为你的JVM已经crash了，即OUT OF MEMORY鸟。
² CPU Load
我们来看一份测试人员提交上来CPU得用率的报告：
| Web Server |
App Server |
DB Server |
| 60% |
98% =_=!(oh my god) |
6% 囧 |
同时平均响应时间好慢啊。
拿过来看了一下代码与设计。。。Struts+Spring+JDBC的一个框架，没啥花头的，再仔细一看Service层。
大量的复杂业务逻辑甚至报表的产生全部用的是javaobject如:List, Hashmap等操作，甚至还有在Service层进行排序、复杂查询等操作。
一看DB层的CPU利用率才6%，将一部分最复杂的业务拿出去做成Store Procedure（存储过程后），再重新运行压力测试。
| Web Server |
App Server |
DB Server |
| 60% |
57% =_=!(oh my god) |
26% 囧 |
同时平均响应时间比原来快了15-16倍。
为什么？？
看看第一份报告，我们当时还查看了数据库服务器的配置，和APPServer的配置是一个级别的，而利用率才6%。。。
数据库，至所以是大型的商用的关系型数据库，你只拿它做一个存储介质，你这不是浪费吗？人家里面设置的这个StoreProcedure的处理能力，索引效率，数据分块等功能都没有去利用，而用你的代码去实现那么多复杂业务比如说多表关联、嵌套等操作，用必要吗？那要数据库干什么用呢？
是啊，我承认，原有这样的代码，跨平台能力强一点，可付出的代价是什么呢？
用户在乎你所谓的跨平台的理论还是在乎的是你系统的效率？一个系统定好了用DB2或者是SQL SERVER，你觉得过一年它会换成ORACLE或者MYSQL吗？如果1年一换，那你做的系统也只能让用户勉强使用一年，我劝你还是不要去做了。在中国，有人统计过5年左右会有一次系统的更换，而一些银行、保险、金融行业的系统一旦采用了哪个数据库，除非这个系统彻底出了问题，负责是不会轻意换数据库的，因此不要拿所谓的纯JAVA代码或者说我用的是Hibernate,ejb实现可以跨数据库这套来说事，效率低下的系统可以否定你所做的一切，一切！