如何进行Java EE性能测试与调优

标签: 何进 java ee | 发表时间:2012-03-24 20:51 | 作者:
出处:http://www.iteye.com
性能测试的目标

性能测试不同于功能测试,不是对与错的检验,而是快与慢的衡量。在进行真正的性能测试之前要先搞清楚目标:

1. 在确定的硬件条件下,可以支持的并发数越大越好,响应时间越快越好。具体需要达到的并发数是多大,要求的响应时间是多快,由产品经理来提出。

2. 在确定的硬件条件下,测试得到最大并发数和相应的响应时间之后。如果增加硬件投入,可以得到怎样的性能提升回报? (系统扩展性和伸缩性测试,Scalability)

这里的硬件条件包括:cpu,memery,I/O,network bandwidth。

性能测试中的基准测试 Benchmarking

与功能测试相似,性能测试也要设计测试用例,不同的是在正式开始你的业务测试用例之前你要先进行一下基准测试。为什么呢?其实就是先要量一下你的硬件的能力,不然,如果你的测试结果不好,你怎么知道是硬件慢还是你的软件的问题。这些硬件测试包括:

1. 网络带宽测试, 你可以通过copy大文件的方式测试你的网络的最大带宽是多少。

2. cpu,你可以利用比较复杂的算法来衡量cpu的快慢

3. memery,这个不用测试,你知道memery的大小

4. IO, 也可以通过copy大文件来测试

这些基准测试用例在后面的调优过程中,还可以用来衡量你修改之后真的变好了吗。



设计你的业务测试用例

比较理想的测试用例就是要尽可能模仿真实世界的情况,这往往做不到,尤其是对于新产品来说。你可以先录制一些用户最常用,最典型的case作为起点。

另外,对于并发的概念需要搞清楚。并发用户,通常是指同时在线的用户,这些用户可以能在用你的系统的不同的功能,注意并不是说大家都在做同一件事情。对某一个事务并发请求是指某一个request的并发调用。

对于后一种并发,你往往需要计算在用户量最大的时候,大概大家都集中的在干哪一件事情,这个请求一定要够快才好。

设计好这两种测试用例以后,在后面的调优过程中,他们就成了衡量你的改进的成效的衡量的标尺。

性能调优

性能调优要从底层开始,基本上要从OS开始,到JVM,Cache,Buffer Pool, SQL,DB Schema, 算法。

一次不要改的太多,改一点,测一下,这可是个慢功夫,需要有耐心。

在执行测试的时候还要注意,要遵循相同的过程,系统需要在重启之后先热身再开始真正的测试,不然你会发现你的测试结果很不一样,琢磨不定。

还有,要注意你的客户端的能力,比如JMeter,很需要内存,别因为客户端不行,误以为是你的系统的问题,那就太乌龙了。

在测试调优的时候,需要借助一些监控工具比如JConsole,来监控系统的状况,找到系统的瓶颈,所谓瓶颈,就是最慢的那个部分,也常表现为100%被占满。比如你的内存或者cpu被用尽了。如果cpu和内存还没有用尽,说明他们在等某个资源。这时候需要用profile工具去寻找,比如JProfile,YourKit。

利用性能监控日志


因为性能的问题不是很容易重现,当product环境中遇到性能问题的时候,如果是数据的问题,也许当你把product 数据copy到你的测试环境中,就能重现比较慢点查询,加以改进。但是如果是并发用户或者网络等运行时环境的问题,你就很难重现。这时,如果你能通过日志看到那些关键的响应慢的方法,也许可以帮助你快点找到问题所在。下面的代码可以帮你做到这一点,仅供参考:



 
  import org.slf4j.Logger; 
     
    public class TraceUtil { 
        final Logger logger; 
        final long threshold = 1000; 
        private long begin; 
        private long offtime = 0; 
        private String threadInfo; 
        private String targetId; 
     
        public TraceUtil(Logger logger, Thread thread, String targetId, long begin) { 
            this.logger = logger; 
            this.threadInfo = thread.getId() + "-" + thread.toString(); 
            this.targetId = targetId; 
            this.begin = begin; 
        } 
     
        public void trace(String targetEvent) { 
            long duration = System.currentTimeMillis() - begin; 
            long increment = duration - offtime; 
            offtime = duration; 
            float percentage = (float) increment / (float) duration * 100; 
            if (duration > threshold && percentage > 20) { 
                logger.error( 
                        "Response time is too large: [{}], {}/{} ({}), {}, {}", 
                        new String[] { threadInfo + "", increment + "", 
                                duration + "", percentage + "%", targetEvent, 
                                targetId }); 
            } 
     
        } 
     
    } 


利用JVM的MXBean找到blocked的点

当你发现JVM占用的cpu很高,而且响应时间比较慢,很可能是被IO或者网络等慢速设备拖住了。也有可能是你的方法中某个同步点(同步方法或者对象)成为性能的瓶颈。这时候你可以利用JVM提供的monitor API来监控:





<%@ page import="java.lang.management.*, java.util.*" %> 
    <%! 
        Map cpuTimes = new HashMap(); 
        Map cpuTimeFetch = new HashMap(); 
    %> 
     
    <% 
    out.println("Threads Monitoring"); 
    long cpus = Runtime.getRuntime().availableProcessors(); 
    ThreadMXBean threads = ManagementFactory.getThreadMXBean(); 
    threads.setThreadContentionMonitoringEnabled(true); 
    long now = System.currentTimeMillis(); 
    ThreadInfo[] t = threads.dumpAllThreads(false, false); 
    for (int i = 0; i < t.length; i++) { 
        long id = t[i].getThreadId(); 
        Long idObj = new Long(id); 
        long current = 0; 
        if (cpuTimes.get(idObj) != null) { 
            long prev = ((Long) cpuTimes.get(idObj)).longValue(); 
            current = threads.getThreadCpuTime(t[i].getThreadId()); 
            long catchTime = ((Long) cpuTimeFetch.get(idObj)).longValue(); 
            double percent = (double)(current - prev) / (double)((now - catchTime) * cpus * 1000); 
            if (percent > 0 && prev > 0) {
    out.println("<li>" + t[i].getThreadName()+"#"+t[i].getThreadId() + " Time: " + percent + " (" + prev + ", " + current + ") ");
    String locked = t[i].getLockInfo()==null?"":t[i].getLockInfo().getClassName();
    out.println(" Blocked: (" + t[i].getBlockedTime() + ", " + t[i].getBlockedCount() + ", " + locked + ")</li>");
    }
        } 
        cpuTimes.put(idObj, new Long(current));   
        cpuTimeFetch.put(idObj, new Long(now)); 
    } 
    %>





同步是性能的一大瓶颈

通过监控发现,大量线程block在一个同步方法上,这样cpu也使不上劲。当你发现性能上不去,IO和网络等慢速设备也不是问题的时候,你就得检查一下是否在某个关键点上使用了同步(synchronizae)。有时候也许是你应用的第三方的jar里面的某个方法是同步的,这种情况下,你就很难找到问题所在。只能在编写代码的时候看一下你引用的方法是否是同步的。



参考阅读

1. Java run-time monitoring 系列文章,比较系统的讲解了jvm的监控

2. Performance Tuning the JVM for Running Tomcat:本文列举了tomcat性能相关的几个关键的jvm 参数

3. 一本系统讲解Java性能的书:Java Performance

4. insideApps,一个事务级别的JavaEE的性能监控开源软件。它希望可以寄存在product环境中,在不影响系统性能的前提下,监控和分析产品的性能。想法很不错。

5. ManageEngine, 一个很强大的监控软件,有免费版。





已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [何进 java ee] 推荐:

如何进行Java EE性能测试与调优

- - ITeye博客
性能测试不同于功能测试,不是对与错的检验,而是快与慢的衡量. 在进行真正的性能测试之前要先搞清楚目标:. 在确定的硬件条件下,可以支持的并发数越大越好,响应时间越快越好. 具体需要达到的并发数是多大,要求的响应时间是多快,由产品经理来提出. 在确定的硬件条件下,测试得到最大并发数和相应的响应时间之后.

红帽的 PaaS 平台 OpenShift 支持 Java EE 6

- Jackphone - ITeye资讯频道
红帽公司刚对其旗下的 PaaS (Platform-as-a-Service) 平台—— OpenShift 做了改进,增加对 Java EE 6 的支持,这使得 OpenShift 成为第一个支持 Jaav EE 6 的 PaaS 解决方案平台. 该免费平台使用了最近刚发布的 JBoss Application Server 7  版本,用于帮助开发者在云端更便捷地构建和发布Java 的应用程序.

影响Java EE性能的十大问题

- - 博客 - 伯乐在线
本文作者是一名有10多年经验的高级系统架构师,他的主要专业领域是Java EE、中间件和JVM技术. 他在性能优化和提升方面也有很深刻的见解,下面他将和大家分享一下常见的10个影响Java EE性能问题. 容量规划是一个全面的和发展的过程标准,预测当前和未来的IT环境容量需求. 制定合理的容量规划不仅会确保和跟踪当前IT生产能力和稳定性,同时也会确保新项目以最小的风险部署到现有的生产环境中.

JBoss AS 7.1全面兼容Java EE 6 Full Profile

- - InfoQ cn
上周发布了 JBoss AS 7.1,这是首款全面兼容Java EE 6 Full Profile的JBoss服务器,继Apache Geronimo和Oracle GlassFish之后,成为了 又一款全面兼容Java EE 6 Full Profile的开源服务器. 去年,JBoss AS 7.0完成了 Java EE 6 Web Profile认证,但Full Profile中还额外包含Java Message Service、WebServices和多项管理技术.

Java EE 7 三大新特性的介绍

- - 博客 - 伯乐在线
013 年 6 月中旬甲骨文公司发布了 Java EE 7,该版本的新特性主要集中在提高开发人员的生产力、加强对 HTML5 动态可伸缩应用程序的支持和进一步满足苛刻的企业需求这三个方面. Java EE 7 使得开发人员可以写更少的样板代码,通过丰富的组件来提供一个完整、全面、集成的堆栈来支持和构建最新的 Web 应用程序和框架,同时提供更具扩展性、丰富性和简易的功能.

Java EE项目中异常设计及处理总结

- - Java - 编程语言 - ITeye博客
异常,为我们处理非正常的业务流程提供了很好的解决方案,如果你有过dbase、c、pascal等过程式语言开发的经历,你一定会深刻体会到,异常机制给你的代码可读行、可维护性带来的好处,同时,程序的健壮性也得到了增强. 在 java项目中,异常设计要注意下面的几点. A、自定义异常的父类,可以选择为RuntimeException或Exception.

遵循Java EE标准体系的开源GIS服务平台架构

- - CSDN博客Web前端推荐文章
传送门 ☞ Android兵器谱 ☞ 转载请注明 ☞ http://blog.csdn.net/leverage_1229. 传送门 ☞ 系统架构设计 ☞ 转载请注明 ☞ http://blog.csdn.net/leverage_1229. 传送门 ☞ GoF23种设计模式 ☞ 转载请注明 ☞ http://blog.csdn.net/leverage_1229.

Java EE企业系统性能问题的原因和解决建议

- - InfoQ cn
Pierre-Hugues Charbonneau(昵称是P-H)是加拿大CGI公司的高级IT顾问和系统架构师. 近日他发表了题为《 导致Java EE企业性能问题的十大原因》的文章,列举了对Java EE企业系统性能影响最大的因素,并做出了很好的建议. 在文中,P-H首先指出,在设计和实现Java EE相关技术的时候,性能问题是我们所要面临的最大挑战之一.

遵循Java EE标准体系的开源GIS服务平台之二:平台部署

- - CSDN博客架构设计推荐文章
传送门 ☞ Android兵器谱 ☞ 转载请注明 ☞ http://blog.csdn.net/leverage_1229. 传送门 ☞ 系统架构设计 ☞ 转载请注明 ☞ http://blog.csdn.net/leverage_1229. 传送门 ☞ GoF23种设计模式  ☞  转载请注明  ☞  http://blog.csdn.net/leverage_1229.

遵循Java EE标准体系的开源GIS服务平台之三:数据发布与访问

- - CSDN博客Web前端推荐文章
传送门 ☞ Android兵器谱 ☞ 转载请注明 ☞ http://blog.csdn.net/leverage_1229. 传送门 ☞ 系统架构设计 ☞ 转载请注明 ☞ http://blog.csdn.net/leverage_1229. 传送门 ☞ GoF23种设计模式.         在GIS服务平台构建完毕之后,我们就要着手在此平台上提供服务以供客户端请求访问.