基于既有J2EE项目构建高性能Web应用方法研究

任女尔+董长青+陈辰

摘要：随着J2EE软件技术积累及其中间件技术的飞速发展，旧项目重构、项目调优等需求也逐渐增多。针对传统研发模式的既有项目进行调优，以低成本、短周期的演进模式适应变化的访问用户数及高并发状态下的快速响应需求，成为大部分中小企业面临的关键技术问题。该文从中间件调优、架构调优的工具、方法入手，提出了一系列分析和解决既有J2EE项目构建高性能Web应用的思路和解决方案。

关键词：J2EE调优；中间件调优；性能优化

中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2017）32-0076-04

1 概述

J2EE技术经过近十年的发展，以其跨平台、可伸缩、灵活度高等特点得到了大规模应用；在Sun、Oracle、IBM等公司及一些开源社区的演进支持下，发展了多种多样、灵活可配的插件、框架等，并不断升级优化。与此同时，传统行业以解决行业信息化问题为主流手段的情况下，并未有效地跟进互联网行业技术迭代更新，引发了生产制造、信息管理随着规模增大、用户增多的情况下Web应用的性能和高并发支撑问题。

本文着手传统技术调优手段及新技术框架升级等方面，以方法、思路以及验证结果为主展示传统J2EE项目的调优过程。

2 传统J2EE项目特点

传统J2EE项目发展迅速，在企业级应用构建中普及率较高，应用场景表现为使用人数百人到千人规模，包含一些基础信息化管理功能，针对特定领域内容有一定的计算和分析功能，针对消息、工作流、文件及图片管理有特定的需求等。

2.1 框架技术及其演进

在2005年左右开始大规模普及的SSH（Struts 2、Spring、Hibernate）框架技术最为常见，逐步演进的技术包含：

1） SpringMVC以更简易、更高性能逐步取代漏洞较多的Struts2；

2） Mybatis以原生sql便于使用的优势抢占Hibernate市场，但由于后者方言支持、自动化强、更关注业务等特点并未被取代；

3） 数据库连接池技术由原来的DBCP、C3P0、Proxool等框架受到缓存策略更优秀、监控支持、扩展支持、并发支持更好的Druid冲击；

4） 随着前后端分离技术的发展，Swagger等调试工具体现良好；

5） 性能监控如Javamelody和JMetrics在高并发调试下逐步展露；

6） 其他框架如Dozer相对于BeanManager等。

相对于传统框架技术，逐步发展的微服务技术从架构的角度从框架到调试工具、从运作研发模式到运维方式都更为灵活方便，是目前常用的互联网架构，如Dubbo+zookeeper、SpringBoot+SpringCloud等可以高效地解决高并发应用相关技术问题，不在本文重点阐述范围内。

2.2 中间件技术

J2EE中间件技术在中小系统中轻便简单、跨平台安装的Tomcat普及率较高，此外在大型系统分布式构建中常用中间件有Weblogic，此外还有Jboss和Websphere等。本文设计相关技术则以Tomcat和Weblogic技术为主进行调优，数据库以Oracle为例进行讲解。

3 总体优化策略及调优团队及工具

J2EE项目调优策略主要分为架构和运维两个大的方向进行。从架构的角度来说，微服务为目前行业架构的主流，因其改动较多、重构成本高，中小企业应急式调优只针对部门框架调整进行。从运维的角度来说，本文主要优化策略包括：CND及Redis缓存、操作系统参数调优、Java应用JVM参数、Tomcat调优、负载均衡等，此外，运维调优还包括多地域部署、DNS、公网及内网链路等策略。从运维的角度支持高并发，主要为先针对单个中间件进行调优、测量，使服务器资源充分利用起来，然后针对集群环境进行部署并测试。

性能调优的工具：系统性能有问题最直接的表现是卡顿，如何判断是网络问题还是应用问题，需要专业的工具来进行测量：

1） nmon工具：用于直观的检测linux环境下CPU、内存、网络及磁盘等的使用情况信息，如图1所示。

点击“C”可以查看CPU，点击“n”可以查看网络如图2所示。

2） GoAccess：实时分析web日志的分析工具。如图3所示，可以查看每个文件对网络的消耗情况。

图3中可以看出，jquery.min.js文件在6分钟网络监控汇总消耗了418MB网络资源。

3） AWR报告及Druid结果：AWR为oracle提供的数据库执行情况报告可以直接导出查看；Druid为数据库连接的技术框架，提供高可靠的数据库连接池和连接控制服务。

4） Gzip测试：可以通过网址测试http：//tool.chinaz.com/Gzips/。如下所示：

5） LoadRunner及Jmeter：LoadRunner对于web页面压测较为方便，Jmeter更轻量级适合接口级测试。本文重点使用LoadRunner，其中loadrunner脚本执行可以设置循环次数、方法等，并可以选择性设置是否缓存浏览器数据。

性能调优的团队：测试人员、运维人员、开发人员、DBA等。其中测试人员主要只性能测试，需要这对各阶段调试结果评估效果并提出问题关键点；运维人员针对部署环境参数、中间件参数等进行调优；开发人员将测试的慢应用逻辑及慢sql等进行调整；DBA调整数据库环境参数，并提出sql修改建议及意见。

3.1 现象及问题分析

部署环境：初步部署环境简单随意，主要审查应用的基础特点；本文选用環境为oracle linux服务器两台分别做数据库和应用服务器，为了检测应用对资源使用情况，服务器性能以低配为主。endprint

初步审查：查看系统首先将nmon启动，随时监控服务器资源使用情况；启动“jstack 2260|more”（2260为当次启动的java进程），然后点击应用系统的响应较慢的功能，观察应用现象及java进程日志。（附图 nmon进程），jstack日志：

随着查阅主要有几个特征：应用CPU利用率较低、数据库CPU利用率稍高、页面图片加载速度慢、console输出大量sql文日志、jstack日志的dump出现很多createconnect过程及Waiting on condition状态。

现象表示，在低并发下，sql文都较长消耗了较多的数据库服务器资源，createconnect说明数据库连接池不足够支撑应用；Wariting on condition代表后台可能因为逻辑处理或网络传输造成响应速度慢，图片因文件过大（最大124K）传输较慢，日志没有合理关闭并且可能出现同步生成日志的情况。进一步可以确认可以从数据库连接池、日志、sql调优、图片压缩、中间件环境参数进行调整。

3.2 调优策略预估

调优一般遵从先单机调试再集群调试、逐步调优并结果验证的原则。当单机调试可以支持系统利用服务器的80%左右资源时考虑集群调优，否则出现集群资源利用率上不去、并发性也上不去的现象。逐步验证结果旨在保证所做策略是行之有效的。在调优策略中，通用的技术手段包含环境参数调优、程序调优及中间件调优。环境参数主要将服务器资源充分释放给应用；程序调优可以采用局部优化程序算法，进一步通过缓存策略将数据库进行数据缓存及业务数据缓存，可以有效地避免重复复杂的逻辑计算。结合初步验证的应用表现监控现象，可以初步确定如下调优方案进行逐步验证：

4 调优实践及结果

第一步：测试环境准备及执行基础参数测试。

测试环境准备：首先制定了基础测试环境准备如下表所示。其中，首次准备配置较高，网络环境较差，无法匹配测试结果，因此降低配置（下表中为降低后的配置），将低配的服务器环境充分利用进行评估。

基础参数测试：准备了一个登录测试用例和一个业务的测试用例；然后根据基础环境参数不调优状态下进行测试；以每秒平均处理事务数作为调优的基准参考参数。

200并发用户下不带缓存TPS：

如图所示，在基准测试时，200用户并发时，每秒事务处理数TPS，在带和不带缓存下分别是38和2.8。

第二步：环境和应用调优。根据一轮分析结果，需要调整环境和软件参数，包括日志切换为异步方式，数据库连接池切换druid，Hibernate开启二级缓存，操作系统开启限制级别。

1） 日志切换，将同步生成日志改为异步：

2） 数据库连接池从dbcp切换到Druid，并设置数据库连接参数，进行监控：

监控可以直接查看各个点击功能对数据库操作的影响，并提供具体慢sql执行时间，从而针对性优化业务逻辑和算法实现。此外，从切换后jstack可以查看到持续创建数据库连接的日志消失了，druid对该方面的控制能力更优。

3） Hibernate开启缓存和批量处理：一级、二级缓存开启，查询的批量处理： hibernate.jdbc.fetch_size=50，hibernate.jdbc.batch_size=30。

4） 系统级参数：开启系统级参数可以非常放开系统对单个用户、应用的资源限制，从而使应用能够充分利用硬件资源。

修改/etc/sysctl.conf，放开网络限制：

5） 调整图片和基础压缩。传统web应用中，页面和图片的大小都比较大，一般都在几百KB甚至更高。前面每一步调整，均进行相应的测试，测试发现，网络环境受限，因此系统的CPU和内存使用量无法偏低，无法达到合理利用的70%-80%范围。基础能够确认方案要提升数据传输效率。因此根据访问的goaccess记录结果，将大图片进行修正为web版式，再基于tomcat/nginx进行传输数据的压缩。

经过前五部分调优测试，测试结果提升到500用户在线下平均3.32s完成数据响应处理，较起始200并发下平均响应时间59s有了大幅度提升。

第三步，中间件调优：一方面从memcached缓存入手（也可采用redis，性能差异较小），另一方面从tomcat I/O方式调优。

缓存调优主要通过将hibernate二级缓存防止到memcached中，如图16分别测试了登录带缓存、不带缓存，业务带缓存和不带缓存四个场景添加和不添加缓存下的磁盘IO状态。

memcached缓存处理：IO处理能力提升2%，命中率在70%。

常用的中间件tomcat支持BIO、NIO及APR三种接收请求的处理方式。BIO为阻塞式，tomcat默认I/O方式，但其對高并发静态文件处理能力非常有限，线程处理数据阻塞状态较多；NIO为非阻塞式，相对来说很大程度上提升了并发处理能力；apr则从底层调用方式上进行了彻底的改进，相当于直接从操作系统级解决IO调用问题，但是必然面临着跨平台性降低，需要在部署时专门针对APR模式安装底层支持。APR模式大幅度提升了服务器的处理和响应能力，是tomcat运行高并发web应用的最佳模式。Tomcat启动时，可以通过启动的标示看出以哪种I/O运行，如下图为BIO启动标示。

最终调优达到了500并发下，平均登录耗时2.935s。

5 总结

综合分析，本文通过中间件进行图片压缩处理、通过图片加工web样式、软件sql调优等最终使得单tomcat应用的性能大幅度提升，并发响应支撑能力提升了2.5倍，响应时间降低了25倍。基于该方案，可以进一步进行分布式部署：应用级部署并发性与硬件、部署节点数成线性正比，数据库需再进行测试调整。整体方案在不需要大幅度调整软件架构的情况下达到了较为理想的效果，对传统IT行业J2EE优化具有重要的指导意义。endprint