不是对与错的检验，性能测试不同于功能测试。而是快与慢的衡量。进行真正的性能测试之前要先搞清楚
可以支持的并发数越大越好，1.确定的硬件条件下。响应时间越快越好。具体需要达到并发数是多大，要求的响应时间是多快，由产品经理来提出
测试得到最大并发数和相应的响应时间之后。如果增加硬件投入，2.确定的硬件条件下。可以得到怎样的性能提升回报？系统扩展性和伸缩性测试Scalabl
这里的硬件条件包括：cpumemeriI/Onetworkbandwidth，性能测试中的基准测试 Benchmarking，性能测试也要设计测试用例，与功能测试相似。不同的正式开始你业务测试用例之前你要先进行一下基准测试。为什么呢？其实就是先要量一下你硬件的能力，不然，如果你测试结果不好，怎么知道是硬件慢还是软件的问题。这些硬件测试包括：可以通过copi大文件的方式测试你网络的最大带宽是多少。1.网络带宽测试。cpu可以利用比较复杂的算法来衡量cpu快慢
知道memeri大小3.memeri这个不用测试。
4.IO也可以通过copi大文件来测试
还可以用来衡量你修改之后真的变好了吗。这些基准测试用例在后面的调优过程中。
设计你业务测试用例
这往往做不到尤其是对于新产品来说。可以先录制一些用户最常用，比较理想的测试用例就是要尽可能模仿真实世界的情况。最典型的case作为起点。
对于并发的概念需要搞清楚。并发用户，另外。通常是指同时在线的用户，这些用户可以能在用你系统的不同的功能，注意并不是说大家都在做同一件事情。对某一个事务并发请求是指某一个request并发调用。
往往需要计算在用户量最大的时候，对于后一种并发。大概大家都集中的干哪一件事情，这个请求一定要够快才好。
后面的调优过程中，设计好这两种测试用例以后。就成了衡量你改进的效果的衡量的标尺。
基本上要从OS开始，性能调优要从底层开始。JVMCachBufferPoolSQLDBSchema算法。改一点，一次不要改的太多。测一下，这可是个慢功夫，需要有耐心。要遵循相同的过程，执行测试的时候还要注意。系统需要在重启之后先热身再开始真正的测试，不然你会发现你测试结果很不一样，琢磨不定。要注意你客户端的能力，还有。比方JMeter很需要内存，别因为客户端不行，误以为是系统的问题，那就太乌龙了，需要借助一些监控工具比方JConsol来监控系统的状况，测试调优的时候。找到系统的瓶颈，所谓瓶颈，就是最慢的那个局部，也常表现为100%被占满。比方你内存或者cpu被用尽了如果cpu和内存还没有用尽，说明他等某个资源。这时候需要用profil工具去寻找，比方JProfilYourKit
当product环境中遇到性能问题的时候，因为性能的问题不是很容易重现。如果是数据的问题，也许当你把product数据copi测试环境中，就能重现比较慢点查询，加以改进。但是如果是并发用户或者网络等运行时环境的问题，就很难重现。这时，如果你能通过日志看到那些关键的响应慢的方法，也许可以协助你快点找到问题所在下面的代码可以帮你做到这一点，仅供参考：
importorg.slf4j.Logger;
publicclassTraceUtil{
finalLoggerlogger;
finallongthreshold=1000;
privatlongbegin;
privatlongofftim=0;
privatStringthreadInfo;
privatStringtargetId;
Threadthread, publicTraceUtilLoggerlogger.StringtargetId,longbegin{
this.logg=logger;
this.threadInfo=thread.getId+"-"+thread.toStr;
this.targetId=targetId;
this.begin=begin;
}
publicvoidtraceStringtargetEv{
longdurat=System.currentTimeMilli-begin;
longincrement=durat-offtime;
offtim=duration;
floatpercentag=floatincrement/floatdurat*100;
ifdurat>threshold&&percentag>20{
logger.error
{}/{}{}, "Responstimeistoolarge:[{}].{},{}",
increment+"", newString[]{threadInfo+"".
percentag+"%", durat+"".targetEvent,
targetId};
}
}
}
利用JVMMXBean找到block点
而且响应时间比较慢，当你发现JVM占用的cpu很高。很可能是被IO或者网络等慢速设备拖住了也有可能是方法中某个同步点（同步方法或者对象）成为性能的瓶颈。这时候你可以利用JVM提供的monitorAPI来监控：
java.util.*"%> <%@pageimport="java.lang.management.*.
<%!
MapcpuTim=newHashMap;
MapcpuTimeFetch=newHashMap;
%>
<%
out.println"ThreadMonitoring";
longcpu=Runtime.getRuntim.availableProcessor;
ThreadMXBeanthread=ManagementFactory.getThreadMXBean;
threads.setThreadContentionMonitoringEntrue;
longnow=System.currentTimeMilli;
fals; ThreadInfo[]t=threads.dumpA llThreadfalse.
forinti=0;i<t.length;i++{
longid=t[i].getThreadId;
LongidObj=newLongid;
longcurrent=0;
ifcpuTimes.getidObj!=null{
longprev=LongcpuTimes.getidObj.longValu;
current=threads.getThreadCpuTimt[i].getThreadId;
longcatchTim=LongcpuTimeFetch.getidObj.longValu;
doublpercent=doublcurrent-prev/doublnow-catchTim*cpu*1000;
ifpercent>0&&prev>0{
"+current+""; out.println"<li>"+t[i].getThreadNam+"#"+t[i].getThreadId+"Time:"+percent+""+prev+".
Stringlock=t[i].getLockInfo==null?"":t[i].getLockInfo.getClassNam;
"+t[i].getBlockedCount+", out.println"Blocked:"+t[i].getBlockedTim+"."+lock+"</li>";
}
}
newLongcurrent; cpuTimes.putidObj.
newLongnow; cpuTimeFetch.putidObj.
}
%>
同步是性能的一大瓶颈
大量线程block一个同步方法上，通过监控发现。这样cpu也使不上劲。当你发现性能上不去，IO和网络等慢速设备也不是问题的时候，就得检查一下是否在某个关键点上使用了同步（synchroniza有时候也许是应用的第三方的jar里面的某个方法是同步的这种情况下，就很难找到问题所在只能在编写代码的时候看一下你引用的方法是否是同步的
参考阅读
比较系统的讲解了jvm监控1.Javarun-timmonitor系列文章。
2.PerformTunetheJVMforRunTomcat本文列举了tomcat性能相关的几个关键的jvm参数
3.一本系统讲解Java性能的书：JavaPerformance
不影响系统性能的前提下，4.insideA pp一个事务级别的JavaEE性能监控开源软件。希望可以寄存在product环境中。监控和分析产品的性能。想法很不错。