J2EE及相关技术的优化在基站巡检系统中的应用

辛晓鹏++吴伟明

摘要：通信产业正在快速发展，基站的种类和数量因此也得到大幅度提升，为了保障基站的正常运转，基站巡检工作变得日益繁重。传统的基站巡检方式耗费大量人力物力，但效果却不尽如人意。随着J2EE技术的日趋成熟，基于J2EE及相关技术的各类WEB应用系统不断涌现，并为各行业带来了工作便利，基站巡检系统正是其中之一。本文在分析J2EE体系架构及各类相关技术自身特点的基础上，结合基站巡检领域的行业特点，从多个方面提出优化策略，并将整套优化方案应用于基站巡检系统的改进中，使其性能优良、用户满意度较高。

关键词：J2EE；基站巡检；优化；WEB应用系统

中图分类号：TP311.1

文献标识码：A

DOI：10.3969/j.issn.1003-6970.2015.09.022

0 引言

近年来，随着世界经济的快速发展与科技水平的突飞猛进，通信业逐渐成为全世界发展速度最快的产业之一。在我国，得益于政府对通信领域发展的高度重视，通信行业始终保持快速增长趋势，通信网络的规模不断扩大，其中最显著的特征之一就是各大通信运营商旗下的通信基站种类和数量得到大幅度提高。

通信基站设备的正常运行是通信活动顺利进行的保障。为了确保国家通信事业的安全运转以及充分保障人民大众对通信的日常需求，我们对基站的稳定性和可靠性都提出了更高的要求。然而基站设备不可避免的会出现一定的故障率，所以对基站进行高效的安防巡检成为了保证基站设备正常运转的一项核心工作。

传统的基站巡检主要依靠派遣人工巡检加手工纸质记录的方式，而这种方式存有一定的弊端。近年来，信息技术与网络技术飞速发展并得到广泛普及，尤其是当SUN公司推出了J2EE架构规范并经过近些年的发展与改进后，采用J2EE架构及B/S模式的企业级WEB应用系统更是以其较低的硬件需求、良好的可伸缩性、灵活性和易维护性、较短的开发周期而得到广泛的应用。当前，各行业都在大力推行办公自动化，好的应用系统可以为企业优化办公流程，降低管理成本，提升工作效率。因此将基站巡检工作与基于J2EE架构的开发技术相结合，设计出专属的、现代化的基站巡检管理系统，可以在很大程度上解决传统巡检方式中的各类问题。但J2EE架构技术并非完美，特别是当其与特定领域相结合时，更是有较大的优化空间。本文对J2EE架构及相关技术进行了探讨分析，并结合基站巡检工作中的实际特点，提出切实可行的优化方案并应用到基站巡检系统中。

1 基站巡检及传统巡检方式

1.1 基站巡检的现实意义

中国通信业高速发展，各大通信运营商旗下的通信基站及站内设备数量也得以迅猛增加。配置了各类通讯设备的基站机房作为通信数据交换与存储的重要场所，是构建通信网络系统的核心环节，也是进行通信工作的物质基础。可以说，上至确保国家通信事业的安全高效运行，下到充分保障人民群众对通信活动的日常需求，都需要基站能够稳定、持久、可靠的运转。然而基站设备不可避免的会出现一定的故障率，而且基站大多都采用市电供电，较不稳定，各种意外的停电、跳闸等情况也时有发生。因此对基站进行高效的安防巡检成为了保证基站及各项设备正常运转的一项核心工作。现阶段，各大通信运营商的运维部门均采用了对基站进行定期的安防巡检和不定期的故障排除这种巡检工作制度。

1.2 传统巡检方式及其弊端

传统的基站巡检主要依靠人工派遣巡检加手工纸质记录的方式，即由管理人员划分基站区域，逐层审批后派遣专业的巡检人员到指定基站进行巡检，并通过纸质记录的形式保存每次的巡检记录数据。

这种巡检方式看似合理，实际上存有很大的弊端。首先纸质记录的形式在进行数据统计管理环节时只能由人工来完成，大量的记录数据会给统计人员带来极大的困难，工作效率低下；并且大规模的记录数据会造成纸张的大量耗费，不利于企业推行节能减排；此外，对基站的巡检采用人工派遣加手工记录的形式，容易出现由于人为疏忽而造成的数据的漏记或错记情况，而且对巡检人员是否准确及时到位进行检查，巡检及维护人员填写的巡检数据是否真实有效都很难进行核查。

传统的基站巡检方式存有种种弊端，都严重制约了巡检这一通信领域关键维护环节的作用发挥。各大运营商往往都在基站运维工作中投入了大量的人力物力，但效果并不尽如人意。

2 基站巡检系统

基站巡检系统采用主流的J2EE架构并附带Android智能终端，集基站安防巡检、故障检修派发、巡检记录综合统计及查询、电量数据检测统计和系统综合管理等多项功能于一体，实现了对巡检数据的便捷采集、智能归纳统计。巡检系统包含了以往巡检过程中需要填写的多种纸质表格，管理人员在派遣巡检任务或验收结果等环节，只需通过填写相应的电子表单即可完成；而在统计巡检数据等环节，也只需简单输入查询的限定条件，即可获取各项统计结果，数据清晰明了；巡检人员在外出进行安防巡检或故障检修等工作时，智能终端会定位确认出勤，并自动列出待完成的电子表单，操作简单易懂，使得巡检人员无需再手动填写大量纸质表格，只需使用终端便可轻松完成工作，并可实时上传数据至服务器，由系统自动对数据进行归类和存储管理。基站巡检系统充分实现了基站安防巡检工作中的信息化与智能化，并提升了管理上的科学性与规范性。

然而基站巡检系统也并非是完美的，还存有一定的性能提升的空间。首先，该系统基于J2EE架构开发，而J2EE架构本身有着复杂性与多样性的特点，其各项技术模块都会提供多种参数作为不同应用环境下的选择，如果仅仅是将不同模块的技术简单组合，最终系统的运行效率通常不会很理想。其次，为特定的行业开发的专属应用系统往往会带有这个行业的特点，基站巡检工作中最重要的内容便是巡检数据，基站巡检系统中所有的功能也都应该是围绕数据而展开。因此，应用系统与数据库之间的各类数据操作的优化程度以及数据库性能的优化水平也将在很大程度上决定系统的整体运行效率。

3 优化策略与应用

3.1 应用服务器调优

Tomcat是Apache软件基金会下的一个核心项目，由Apache、Sun和其他公司及个人共同开发而成。Tomcat服务器是目前比较流行的一款免费的、开源的、轻量级Web应用服务器，因为其拥有运行时占用系统资源小，扩展性好，且支持负载平衡与邮件服务等开发应用系统常用的功能等优点，深受J2EE开发从业人员的认可，在中小型Web应用系统和并发访问用户量并非海量的场合下被广泛使用。考虑到基站巡检系统的数据规模以及用户量级别，选用Tomcat服务器是极其合适的。

Tomcat服务器在默认配置情况下，性能难以充分发挥。为了提高其处理请求的性能，在实际的应用生产环境中，需要对Tomcat进行性能调优。

3.1.1 JVM调优

Tomcat默认可使用的内存为128MB，这在实际的应用项目中是远远不够的，需要调大。可通过命令行的方式改变虚拟机使用内存的大小。如表1所示有两个参数用来设置虚拟机使用内存的大小。

这两个参数都可根据需要进行设置。初始化堆的大小代表了虚拟机在启动时向系统申请的内存的大小，如果虚拟机启动时设置使用内存较小却有许多对象需要初始化，虚拟机就必须重复地增加内存来满足使用，导致性能受影响，因此需要把“-Xms”参数调大一些，尽可能向最大值靠近；而堆的最大值受限于系统使用的物理内存，一般应用程序会因为维持一定量的持久对象而占用部分内存，当应用程序需要的内存超出堆的最大值时虚拟机就会提示内存溢出，并且导致应用服务崩溃，通常情况下，堆的最大值建议设置为可用物理内存的80%。

若要调整Tomcat的初始内存和最大内存需向JVM进行声明，方法为在Windows系统下的文件{tomcat_home}/bin/catalina.bat，或是Linux下的文件{tomcat home}/bin/catalina.sh的前面，增加如下设置：

JAVA_OPTS=-Xms[初始化内存大小]-Xmx[可以使用的最大内存]

例如：JAVA一OPTS=-Xms1024m-Xmx2048m表示初始化内存1024MB，可以使用的最大内存为2048MB。

此外，还需要考虑到Java的垃圾回收机制。虚拟机的堆大小决定了虚拟机花费在垃圾回收上的时间和频度。调整堆大小的目的是将垃圾收集的时间最小化，以在特定的时间内处理请求的能力最大化。一般说来，使用物理内存的80%作为堆大小是比较合适的。

3.1.2 修改Connector运行模式

Tomcat支持以下三种Connector运行模式：

（1）BIO（Blocking I/O），即阻塞式I/O操作，表示Tomcat使用的是传统的Java I/O操作方式（即Java.10包及其子包）。由于使用的是同步阻塞原理，BIO模式是三种模式中性能最低的一种。

（2）NIO（New I/O），是Java SE l.4及后续版本提供的一种较新的I/O操作方式（即Java.nio包及其子包）。Java.mo是一个基于缓冲区、并能提供非阻塞I/O操作的Java API，因此NIO也可看作是Non-blocking I/O的缩写。该模式拥有比传统I/O操作（BIO）更好的并发运行性能。

（3）APR（Apache Portable Runtime），即Apache HTTP服务器的支持库。该模式下实现的是异步非阻塞，可以说是从操作系统层面解决I/O阻塞问题，因此运行性能也是三种模式中最好的。

可以看到，APR模式是在Tomcat服务器上运行大访问量或高并发量应用系统的首选模式。但由于较早版本的Tomcat并不是默认支持该模式，需要额外安装三个组件：APR库、OpenSSL库以及JNI wrappers for APR used by Tomcat（libtcnative），并将Tomcat安装目录下的server.xml文件中对应的Connector节点的protocol属性值改为“org.apache.coyote.httpll.HttplIAprProtocol”才可启用该模式。而从7.0.30版本Tomcat开始，已经支持并默认在该模式下运行，因此我们可以选择使用最新版本的Tomcat或是在旧版本上进行安装配置。

3.2 数据库调优

MySQL是一款基于SQL的C/S模式关系型数据库管理系统，是目前市面上最流行的通用数据库管理系统之一，凭借其较好的可移植性，优异的响应速度，高可靠性和安全性等特点得到了越来越多用户的青睐。此外，MySQL作为一款开源的软件，任何人员都可以免费获得，而且其公开的源代码和详细的用户手册为数据库技术的进一步优化研究提供了便利，因此MySQL数据库在中小型企业级的应用系统中被广泛使用。考虑到基站巡检系统的基站巡检数据量规模以及使用人员的访问频率，选用MySQL是极其合适的。

3.2.1 存储引擎选择

MySQL默认配置了多种存储引擎，其类型主要有：MyISAM、InnoDB、NDB、Memory（HEAP）、Archive等。每一种类型，都有其各自特点，以下对各种常用的存储引擎进行介绍与分析：

（l） MyISAM存储引擎，特点是不支持事务，也不支持外键，但查询速度较快，适合OLAP（Online Analytical Processing，联机分析处理）应用。每个MyISAM表在磁盘上存储成3个文件，其中文件名和表名都相同，扩展名分别为frm（存储表定义）、MYD（MYData，存储数据）和MYI（MYIndex，存储索引）。MySQL-5.0版本之前，MyISAM默认支持的表大小仅为4G，从MySQL-5.0以后，默认支持256T的单表数据。此外，MyISAM只缓存索引数据。

（2）InnoDB存储引擎，特点是支持外键、行锁、非锁定读、从MySQL-4.1版本开始支持每个InnoDB引擎的表单独放到一个表空间里。InnoDB通过使用MVCC（Multi-Version Concurrency Control，多版本并发控制）来获取高并发性，并且实现SQL标准的4种隔离级别，并使用一种被称成Next-Key Locking的策略来避免幻读现象。除此之外InnoDB引擎还提供了插入缓存、二次写、白适应哈希索引、预读等高性能技术。

（3）NDB存储引擎，特点是数据存放在内存中，因此主键查找的速度极快，并且从MySQL-5.1版本开始可以将非索引数据放到磁盘上。NDB之前的缺陷是Join查询是在MySQL数据库层完成的，而不是在存储引擎完成的，复杂的Join查询需要巨大的网络开销，速度很慢。好在从MySQL cluster7.2版本开始此问题已经被解决，Join查询效率提高了近百倍。

（4）Memory存储引擎，同样会将数据放到内存中，默认使用Hash索引，不支持TEXT和BLOB类型，并且varchar是按照char的方式来存储的。MySQL数据库在使用Memory存储引擎作为临时表存储中间结果集时，如果中间集结果大于Memory表的容量设置，又或者中间结果集包含TEXT和BLOB列类型字段，MySQL会把它们转换为MyISAM存储引擎表而放到磁盘上，因此会对查询产生较大的性能影响。

（5）Archive存储引擎，特点是只支持Select和Insert操作，但插入速度较为高效而对查询的支持相对较差，从MySQL-5.1版本开始支持索引，压缩能力较强，非常适合存储大量的、独立的、作为历史记录存储而不经常被读取的数据，因此主要用于归档数据的存储。

可以看到，不同的存储引擎，其特点及应用场景各不相同。在基站巡检系统中，类似员工信息表以及基站信息表等此类表中的数据都较为固定，添加新数据或者对原有数据进行修改的情况远少于读取已有数据，即对该类数据表的的访问中，查询的比率远大于插入、修改或删除，因此对该类表的查询速度是我们最为关心的。综合考虑各引擎的特点，选用MyISAM是较为合适的。

而对于巡检记录表以及异常信息统计表等存放每次基站巡检具体结果的数据表，主要的操作会是插入与读取数据，而且存在对同一个表并发访问的可能性，此时访问速度将不再是我们最为关心的方面，应从事务安全等角度综合考虑数据表的引擎选择问题。综合分析各引擎的特点，此类表选用InnoDB是较为合理的。

由于从MySQL-5.5.5版本开始，InnoDB被选作为MySQL的默认存储引擎，因此在创建新表时，若未加特殊说明，该表的存储引擎都将默认选择InnoDB。如需更改数据表的存储引擎，可通过以下两种方式：一是选用数据库管理工具，通过修改表属性中的“存储引擎”一项来进行更改；二是在MySQL白带的命令行工具下通过输入命令来更改，例如欲修改数据表table 1的存储引擎为MyISAM，则在命令行工具中输入命令“alter table table_l engine=MyISAM；”即可。

3.2.2 合理使用索引

索引是存储引擎用于快速找到在某列中有特定值的记录的一种数据结构。在不使用索引的情况下，MySQL必须从第1条记录开始依次向后扫描整个表直到找出相关的行。表的数据量越大，花费时间越多。但如果表中查询的列上设有索引，MySQL能快速定位到一个位置并进入到数据表文件中去搜寻，而没有必要再查找所有数据。因此，索引将会对表的查询速度有极大提升。

需要强调的是，索引的建立方式是否适当是影响数据库性能的关键所在，创建索引也并非在所有情况下都是最好的解决方案。总的来说，只有当索引在帮助存储引擎快速查找到记录上带来的提升远大于其本身造成的额外开销时，索引才可以称得上是有效的。对于非常小的数据表，大部分情况下简单的全表扫描更为直接、高效，因此不建议额外添加索引；而对于中到大型的表，索引对效率的提升将会非常明显；但是对于特大型的表，建立和使用索引的代价将急剧增长。这种情况下，创建索引对于提升查询速度的帮助是极小的，而且对于海量级别的数据，仅仅定位单条记录意义已不大，通常都会使用区块级别元数据来替代索引技术，此时应该转为重点考虑分区技术。

此外，添加索引应遵从以下几个原则：

（l）添加索引的列，应该是经常出现在“where语句”中或是“order by”、“group by”之后的过滤条件中的字段，并根据实际情况选用合适的索引种类；

（2）在联合查询或子查询等多表操作时的关连字段建议添加索引；

（3）选择在某列添加索引时，应充分考虑该列中值的分布。对于数据均为惟一值的列，索引的效果最好，而具有多个重复值的列，索引效果则会较差。

（4）不要认为索引是“越多越好”，每添加一个索引都要占用额外的存储空间，并降低写操作的性能。在修改表的内容时，索引必须进行更新，有时甚至需要重构，因此，索引越多，花费的时间会越长。如果创建了一个很少利用或从不使用的索引，那么会不必要地拖慢表的修改速度。此外，创建多余的索引也会给查询优化带来了更多的工作。索引太多，有可能会使MySQL选择不到所应使用的最好索引。只保持所需的最少索引有利于提高查询效率。

3.3 其它相关技术优化

3.3.1 使用Ajax优化页面显示

传统的Web页面访问采用同步交互模式，由客户端向服务器端发送请求，服务器接到请求后进行一系列的处理后再把结果返回到客户端。在服务器处理的整个过程中，客户端必须等待，直到获取服务器的响应数据后才能进行后续的处理，个别情况下还可能需要再次发送新的请求并继续等待响应。如果交互的数据量较小，则此种交互模式可能不会暴露出太多问题，然而一旦交互数据量变大，服务器端的待处理业务一多，响应时间就会变长，显示在浏览器中的将会是一片空白。此外，某些情况下为了更新页面中的部分数据，却不得不对整个页面进行刷新。显然，这种处理方式带来的是极差的用户体验。对于这类问题，我们可以通过利用Ajax技术得到很好的解决方法。

Ajax是使用JavaScript与Web服务器完成数据交换的应用开发技术，本质上是对一组现有技术的无缝整合，其技术实现的核心是XMLHttpRequest对象，可使用该对象在JavaScript脚本中来实现对服务器的异步请求，在不重载页面的情况下与服务器交换据而不用阻塞用户。

Ajax模式的优势有以下几方面：（l）带来更好的用户体验，更新页面无需刷新，减少用户的等待时间；（2）“按需取数据”，可以最大程度地减少冗余请求，避免冗余数据的传输，最大程度的提高带宽利用率；（3）可以把原本由服务器担负的工作转移到客户端，利用客户端的闲置能力来完成处理，减轻服务器端压力；（4）可以灵活调用外部数据，增加了页面显示的多样性。

在基站巡检系统中，Ajax技术可在以下方面带来提升：（1）数据校验。在需要用户进行输入的场景下，可通过异步方式对数据提前进行校验或是查重等工作，并且动态地显示返回的结果信息，无需等到表单提交后才获得处理结果，提供了良好的用户体验。（2）动态获取数据。在需要用户进行选项选择的场景下，当用户选择某级节点后，只把对应分类的下一级数据读取并显示，每次按用户需要动态获得数据，避免冗余，提高资源利用率并且大大缩短用户的等待时间。

3.3.2 使用数据库连接池

通常情况下，直接使用JDBC调用数据库即可满足一个小型应用系统的要求，但是当用户量较大或访问频度较高的情况下，就会出现因数据库的访问量突增而严重拖累服务器的现象。为了解决这一性能问题，可选择使用数据库连接池作为一个缓存的方式解决。

每次数据库连接的建立都是一件既消耗系统内存又耗费时间的工作，而使用连接池，则可预先建立连接。当应用程序需要使用时，就从连接池中直接获取一个连接使用，应用程序使用完毕后，通过closeO方法即可将连接归还到连接池。若并发增加，连接池会不断的自动创建新连接以满足调用需求，直到达到连接池的最大数目；当连接减少甚至没有时，连接池会自动关闭一些，保持最小数目的连接。因此连接池的使用节省了连接建立开销，消除了数据库频繁连接带来的性能影响。

目前流行的常用连接池包括DBCP、C3PO、Proxool、Druid等。其中由阿里巴巴研发的Druid是目前最好的数据库连接池，在功能、性能、扩展性等方面，都超过其他数据库连接池，因此，在基站巡检系统中选择使用Druid。

4 结论

基于J2EE及相关技术的WEB应用系统的性能优化并非一件简单的事，必须在充分了解J2EE体系架构及各类相关技术自身特点的基础上，结合系统所应用于的领域下的行业特点，从设计层面上对性能问题进行全面考虑、综合分析，才能提出切实可行、效果显著的优化方案。本文所提出方案中的各项优化策略，均已应用到基站巡检系统的开发改进中，结合实际应用情况来看，系统运行效果较好，用户满意度较高。