压力测试
不是专职做压力测试这行当的，只能是以自己的经验来以外行人的眼光来说说压力测试，压力测试并不仅仅是个压力测试的过程，而是一个相当系统和复杂的工程，我认为压力测试是为了让系统达到所期望的运行效果以及承受所期望的压力，这也就要求压力测试应该帮助性能调优团队，为其提供一定程度的指导，在这里我不将压力测试和性能调优分的那么清楚了，在我看来，压力测试过程包括了：明确压力测试的目标、制定压力测试方案、进行压力测试、分析压力测试结果、寻找瓶颈并进行调优以达到目标，在这篇blog中来细看下这几个过程以及常用的方法。
不是专职做压力测试这行当的，只能是以自己的经验来以外行人的眼光来说说压力测试，压力测试并不仅仅是个压力测试的过程，而是一个相当系统和复杂的工程，我认为压力测试是为了让系统达到所期望的运行效果以及承受所期望的压力，这也就要求压力测试应该帮助性能调优团队，为其提供一定程度的指导，在这里我不将压力测试和性能调优分的那么清楚了，在我看来，压力测试过程包括了：明确压力测试的目标、制定压力测试方案、进行压力测试、分析压力测试结果、寻找瓶颈并进行调优以达到目标，在这篇blog中来细看下这几个过程以及常用的方法。
明确压力测试的目标
通常来说（注意是通常），压力测试的目标有这么几点：
1、评测系统是否满足压力支撑的要求
要评测系统是否满足压力支撑的要求，同样要做的就是需要明确定义系统需要支撑多大的压力，例如：
机器的配置：CPU、内存、硬盘、etc.
网络条件：100M
操作系统：Linux core: 2.6
当并发数为10用户时，系统应能在20ms内响应完毕（这个时候的TPS为500），系统的load需在2以下；当并发数为100用户时，系统应能在 50ms内响应完毕（这个时候的TPS为2000），系统的load需在4以下；当并发数为200用户时，系统应能在80ms内响应完毕（这个时候的 TPS为2500），允许其中有千分之一的出错率，系统的load需在6以下，在压力测试的过程中，只要其中的任何指标未达到，均可判定系统尚未达到压力的目标。
实际的压力测试的这个指标会比我这里举的例子复杂很多，例如还需要考虑网络流量、内存消耗、IOPS、连接数等等。
这里面压力测试隐藏的目标是为容量规划提供一定的指导，例如目前的系统在某种配置的情况下单台机器能承受的最大并发数为100用户，那么如果系统的高峰压力是1000的话，如果系统支撑无损水平扩展的话就意味着需要10台这类配置的机器，这一步同样是经过测试的。
2、预估系统上线运行的状况
毕竟通常压力测试环境和线上的环境是会有很大的不同的，压力、数据量、硬件环境等，基本上只能是根据线下的环境的情况进行一定比例的对比后计算来预估，这里面很重要的是要预估系统上线后正常情况下的表现状况、一定的增长比率后的运行状况以及风险点（例如当并发用户数增长到多少时、系统load到多少时可能会出现问题）。
这一个目标我觉得非常难达到，但随着经验，我相信是可以做到的，如果能做到这种效果的话是会有很大的帮助的。
以上这个两个目标基本是压力测试都要达到或希望达到的，而具体有可能会因为系统的业务的具体情况会制定其他不同的目标。
制定压力测试方案
这步是压力测试整个过程中最难的步骤之一，为了能够测试出系统是否符合压力支撑的要求以及评估上线的表现，通常我们会希望搭建出和生产环境完全相同的环境，但这就是最麻烦的一点了，基本上是不太可能的，因此通常能采取的方法会是：
1、做等比例的缩放
按照生产环境的情况做一定比例的缩放，例如生产环境的数据量为1亿条，那么测试环境等比缩放到5000w条，生产环境的处理速度的情况…；
2、更差环境、更高压力的测试
采取比生产环境更差的机器配置、网络环境来进行测试，例如ebay的要求是能够承受10x的压力。
3、仿真测试
据资深人士而言，仿真测试要做到基本是不太可能的，仿真测试首先要求的是收集到生产环境中的运行状态的数据，然后在测试环境中编写程序来做到模拟生产环境运行的效果，这个难度基本是非常高的。
我自己现在做压力测试更多采取的做法是以上三种方法的合集。
在确定了测试方法后，就基本可以确定压力测试的环境了，环境确定好后需要做的是压力测试的案例或场景了，在压力测试的案例中需要涵盖正常场景以及异常的场景，正常场景是非常容易做出来的，只是需要根据生产环境收集的数据（例如不同级别的用户比例通常是7:2:1）或预估的数据来搭建相应的测试案例，异常场景则是比较复杂的，需要考虑很多的因素，例如数据库出现异常、网络出现异常等，这里我觉得通常的做法是画出正常场景的处理流程，然后划分交互边界的信任边界，对于所有的第三方交互都认为是不可信任，例如不能信任调用数据库是一定会快的，或一定会成功的，在异常场景中应涵盖这些信任边界的异常状况的测试，这些对于高可用性的系统而言是非常重要的，几个9的成败就在此了，^_^，当然，高可用性又是个更复杂的话题，不在这里讲。
在压力测试方案中还需确定的是考评的指标，通过会包括：tps、系统load等等。
进行压力测试
相对来讲，在有了压力测试方案后，这一步并不是什么太复杂的事情，只是需要选择一个和压力测试方案比较符合的工具来执行，例如jmeter、 loadrunner等，当然，这些工具相对来说也是比较复杂的，而且之间的差距也是比较大的，至少目前来看，jmeter和loadrunner的差距还是不小的，尤其是需要进行高压力的测试时。
分析压力测试结果
这步同样是压力测试中很难的一步，在这一步需要做出的根据压力测试的结果分析出系统的具体表现情况，判定系统是否能够满足压力指标。
以loadrunner产生的分析结果图而言，通常需要分析以下图：
1、Total Transactions per Second
这张图中显示了系统在进行压力测试过程的TPS的变化情况，从这张图中我们可以看到系统的TPS的情况，通常来讲，随着用户数的增加，TPS应该是呈一定比率的增长的，等增长到一定程度后会达到瓶颈，甚至开始下降，这也是TPS的瓶颈值了，这张图可以帮助我们评估系统的TPS是否符合要求。
另外，在这张图中，我们可以看到系统从什么时候开始出现出错的transactions，从而判断出错率是否在可接受的范围。
2、Transaction Response Time Under Load
这张图非常的重要，借助这张图我们可以分析随着用户数增加的情况下，系统的劣化状况，最佳状况当然是一条直线，但这基本是不可能的，毕竟资源是有限的，需要判断的是劣化的程度是否为可接受范畴。
另外就是需要关注数据中90%的用户的响应时间的状况，如果少量用户响应慢是可接受的话，那么有可能在之上指标不达标的情况下仍然满足了压力指标。
3、Unix Resources
这张系统load图自然是非常的重要，借助这张图大致可以判断系统随着用户数的增长消耗的资源的变化情况，这对于调优以及容量规划而言是很重要的，但还是得取决于应用本身，:)。
loadrunner还提供了其他方面很多的图，可以根据考评的要求来自行进行分析。
寻找瓶颈并进行调优以达到目标
这步不属于压力测试范畴，但还是在这里稍微讲讲，毕竟压力测试结束后如果系统没达标的话就必须进行这步了。
寻找瓶颈，这自然是非常难的事了，通常系统达不到要求的状况都会是随着用户的增长，响应时间劣化的过于厉害，在这样的情况下首先得观察系统硬件资源的变化情况，如果是硬件资源耗尽的话，需要查查为什么资源被耗尽，假设最后判断确实需要耗费这么多的硬件资源的话，也许需要考虑增加硬件资源或是水平扩展，否则的话可能需要从软件层面相应的优化系统了，这样的话可以进入下一步了。
如果不是硬件资源的限制的话，得在系统中从头到尾设置时间跟踪filter，从而判断响应时间劣化的原因，看看是系统中哪些步骤造成的，这个是细致活了，有可能要查非常久。
其实这里说的还是相当的简单了，在寻找瓶颈的过程中是个非常繁琐的过程，需要不断的尝试，硬件的增加、OS的调优、jvm的调优以及软件系统本身的调优等等，这些很多时候需要的是经验，因此某知名人士曾经说过如何寻找瓶颈和调优，其中依靠的一点就是直觉，^_^。
当然，在寻找瓶颈的过程中，可以借助os的工具、java的工具（例如gc打印、jprofiler等）来进行查找。
（ps: 不过感觉很多情况下都是应用本身造成的性能瓶颈，在写程序时稍不注意用错一个数据结构都有可能会导致比较大的问题，所以我现在查找瓶颈的时候更多的还是先从软件本身下手，只是软件性能要做到提升通常来付出较大的代价，这个时候需要权衡）
调优基本上要求对硬件、OS、JDK、数据库甚至软件的实现方式等都要有非常深入的理解，至少要能做到判断出瓶颈因素，然后找相应领域的专家来解决，因此要求是非常高的。
关于性能调优的知识体系这里有篇不错的文章：
http://www.cnblogs.com/jackei/archive/2008/06/27/1231307.html
话题太大了，写到最后发现基本上还是有些泛泛而谈了.
