辛曉鵬++吳偉明

摘要：通信產(chǎn)業(yè)正在快速發(fā)展，基站的種類和數(shù)量因此也得到大幅度提升，為了保障基站的正常運轉，基站巡檢工作變得日益繁重。傳統(tǒng)的基站巡檢方式耗費大量人力物力，但效果卻不盡如人意。隨著J2EE技術的日趨成熟，基于J2EE及相關技術的各類WEB應用系統(tǒng)不斷涌現(xiàn)，并為各行業(yè)帶來了工作便利，基站巡檢系統(tǒng)正是其中之一。本文在分析J2EE體系架構及各類相關技術自身特點的基礎上，結合基站巡檢領域的行業(yè)特點，從多個方面提出優(yōu)化策略，并將整套優(yōu)化方案應用于基站巡檢系統(tǒng)的改進中，使其性能優(yōu)良、用戶滿意度較高。

關鍵詞：J2EE；基站巡檢；優(yōu)化；WEB應用系統(tǒng)

中圖分類號：TP311.1

文獻標識碼：A

DOI：10.3969/j.issn.1003-6970.2015.09.022

0 引言

近年來，隨著世界經(jīng)濟的快速發(fā)展與科技水平的突飛猛進，通信業(yè)逐漸成為全世界發(fā)展速度最快的產(chǎn)業(yè)之一。在我國，得益于政府對通信領域發(fā)展的高度重視，通信行業(yè)始終保持快速增長趨勢，通信網(wǎng)絡的規(guī)模不斷擴大，其中最顯著的特征之一就是各大通信運營商旗下的通信基站種類和數(shù)量得到大幅度提高。

通信基站設備的正常運行是通信活動順利進行的保障。為了確保國家通信事業(yè)的安全運轉以及充分保障人民大眾對通信的日常需求，我們對基站的穩(wěn)定性和可靠性都提出了更高的要求。然而基站設備不可避免的會出現(xiàn)一定的故障率，所以對基站進行高效的安防巡檢成為了保證基站設備正常運轉的一項核心工作。

傳統(tǒng)的基站巡檢主要依靠派遣人工巡檢加手工紙質記錄的方式，而這種方式存有一定的弊端。近年來，信息技術與網(wǎng)絡技術飛速發(fā)展并得到廣泛普及，尤其是當SUN公司推出了J2EE架構規(guī)范并經(jīng)過近些年的發(fā)展與改進后，采用J2EE架構及B/S模式的企業(yè)級WEB應用系統(tǒng)更是以其較低的硬件需求、良好的可伸縮性、靈活性和易維護性、較短的開發(fā)周期而得到廣泛的應用。當前，各行業(yè)都在大力推行辦公自動化，好的應用系統(tǒng)可以為企業(yè)優(yōu)化辦公流程，降低管理成本，提升工作效率。因此將基站巡檢工作與基于J2EE架構的開發(fā)技術相結合，設計出專屬的、現(xiàn)代化的基站巡檢管理系統(tǒng)，可以在很大程度上解決傳統(tǒng)巡檢方式中的各類問題。但J2EE架構技術并非完美，特別是當其與特定領域相結合時，更是有較大的優(yōu)化空間。本文對J2EE架構及相關技術進行了探討分析，并結合基站巡檢工作中的實際特點，提出切實可行的優(yōu)化方案并應用到基站巡檢系統(tǒng)中。

1 基站巡檢及傳統(tǒng)巡檢方式

1.1 基站巡檢的現(xiàn)實意義

中國通信業(yè)高速發(fā)展，各大通信運營商旗下的通信基站及站內(nèi)設備數(shù)量也得以迅猛增加。配置了各類通訊設備的基站機房作為通信數(shù)據(jù)交換與存儲的重要場所，是構建通信網(wǎng)絡系統(tǒng)的核心環(huán)節(jié)，也是進行通信工作的物質基礎?？梢哉f，上至確保國家通信事業(yè)的安全高效運行，下到充分保障人民群眾對通信活動的日常需求，都需要基站能夠穩(wěn)定、持久、可靠的運轉。然而基站設備不可避免的會出現(xiàn)一定的故障率，而且基站大多都采用市電供電，較不穩(wěn)定，各種意外的停電、跳閘等情況也時有發(fā)生。因此對基站進行高效的安防巡檢成為了保證基站及各項設備正常運轉的一項核心工作。現(xiàn)階段，各大通信運營商的運維部門均采用了對基站進行定期的安防巡檢和不定期的故障排除這種巡檢工作制度。

1.2 傳統(tǒng)巡檢方式及其弊端

傳統(tǒng)的基站巡檢主要依靠人工派遣巡檢加手工紙質記錄的方式，即由管理人員劃分基站區(qū)域，逐層審批后派遣專業(yè)的巡檢人員到指定基站進行巡檢，并通過紙質記錄的形式保存每次的巡檢記錄數(shù)據(jù)。

這種巡檢方式看似合理，實際上存有很大的弊端。首先紙質記錄的形式在進行數(shù)據(jù)統(tǒng)計管理環(huán)節(jié)時只能由人工來完成，大量的記錄數(shù)據(jù)會給統(tǒng)計人員帶來極大的困難，工作效率低下；并且大規(guī)模的記錄數(shù)據(jù)會造成紙張的大量耗費，不利于企業(yè)推行節(jié)能減排；此外，對基站的巡檢采用人工派遣加手工記錄的形式，容易出現(xiàn)由于人為疏忽而造成的數(shù)據(jù)的漏記或錯記情況，而且對巡檢人員是否準確及時到位進行檢查，巡檢及維護人員填寫的巡檢數(shù)據(jù)是否真實有效都很難進行核查。

傳統(tǒng)的基站巡檢方式存有種種弊端，都嚴重制約了巡檢這一通信領域關鍵維護環(huán)節(jié)的作用發(fā)揮。各大運營商往往都在基站運維工作中投入了大量的人力物力，但效果并不盡如人意。

2 基站巡檢系統(tǒng)

基站巡檢系統(tǒng)采用主流的J2EE架構并附帶Android智能終端，集基站安防巡檢、故障檢修派發(fā)、巡檢記錄綜合統(tǒng)計及查詢、電量數(shù)據(jù)檢測統(tǒng)計和系統(tǒng)綜合管理等多項功能于一體，實現(xiàn)了對巡檢數(shù)據(jù)的便捷采集、智能歸納統(tǒng)計。巡檢系統(tǒng)包含了以往巡檢過程中需要填寫的多種紙質表格，管理人員在派遣巡檢任務或驗收結果等環(huán)節(jié)，只需通過填寫相應的電子表單即可完成；而在統(tǒng)計巡檢數(shù)據(jù)等環(huán)節(jié)，也只需簡單輸入查詢的限定條件，即可獲取各項統(tǒng)計結果，數(shù)據(jù)清晰明了；巡檢人員在外出進行安防巡檢或故障檢修等工作時，智能終端會定位確認出勤，并自動列出待完成的電子表單，操作簡單易懂，使得巡檢人員無需再手動填寫大量紙質表格，只需使用終端便可輕松完成工作，并可實時上傳數(shù)據(jù)至服務器，由系統(tǒng)自動對數(shù)據(jù)進行歸類和存儲管理?；狙矙z系統(tǒng)充分實現(xiàn)了基站安防巡檢工作中的信息化與智能化，并提升了管理上的科學性與規(guī)范性。

然而基站巡檢系統(tǒng)也并非是完美的，還存有一定的性能提升的空間。首先，該系統(tǒng)基于J2EE架構開發(fā)，而J2EE架構本身有著復雜性與多樣性的特點，其各項技術模塊都會提供多種參數(shù)作為不同應用環(huán)境下的選擇，如果僅僅是將不同模塊的技術簡單組合，最終系統(tǒng)的運行效率通常不會很理想。其次，為特定的行業(yè)開發(fā)的專屬應用系統(tǒng)往往會帶有這個行業(yè)的特點，基站巡檢工作中最重要的內(nèi)容便是巡檢數(shù)據(jù)，基站巡檢系統(tǒng)中所有的功能也都應該是圍繞數(shù)據(jù)而展開。因此，應用系統(tǒng)與數(shù)據(jù)庫之間的各類數(shù)據(jù)操作的優(yōu)化程度以及數(shù)據(jù)庫性能的優(yōu)化水平也將在很大程度上決定系統(tǒng)的整體運行效率。

3 優(yōu)化策略與應用

3.1 應用服務器調優(yōu)

Tomcat是Apache軟件基金會下的一個核心項目，由Apache、Sun和其他公司及個人共同開發(fā)而成。Tomcat服務器是目前比較流行的一款免費的、開源的、輕量級Web應用服務器，因為其擁有運行時占用系統(tǒng)資源小，擴展性好，且支持負載平衡與郵件服務等開發(fā)應用系統(tǒng)常用的功能等優(yōu)點，深受J2EE開發(fā)從業(yè)人員的認可，在中小型Web應用系統(tǒng)和并發(fā)訪問用戶量并非海量的場合下被廣泛使用。考慮到基站巡檢系統(tǒng)的數(shù)據(jù)規(guī)模以及用戶量級別，選用Tomcat服務器是極其合適的。

Tomcat服務器在默認配置情況下，性能難以充分發(fā)揮。為了提高其處理請求的性能，在實際的應用生產(chǎn)環(huán)境中，需要對Tomcat進行性能調優(yōu)。

3.1.1 JVM調優(yōu)

Tomcat默認可使用的內(nèi)存為128MB，這在實際的應用項目中是遠遠不夠的，需要調大?？赏ㄟ^命令行的方式改變虛擬機使用內(nèi)存的大小。如表1所示有兩個參數(shù)用來設置虛擬機使用內(nèi)存的大小。

這兩個參數(shù)都可根據(jù)需要進行設置。初始化堆的大小代表了虛擬機在啟動時向系統(tǒng)申請的內(nèi)存的大小，如果虛擬機啟動時設置使用內(nèi)存較小卻有許多對象需要初始化，虛擬機就必須重復地增加內(nèi)存來滿足使用，導致性能受影響，因此需要把“-Xms”參數(shù)調大一些，盡可能向最大值靠近；而堆的最大值受限于系統(tǒng)使用的物理內(nèi)存，一般應用程序會因為維持一定量的持久對象而占用部分內(nèi)存，當應用程序需要的內(nèi)存超出堆的最大值時虛擬機就會提示內(nèi)存溢出，并且導致應用服務崩潰，通常情況下，堆的最大值建議設置為可用物理內(nèi)存的80%。

若要調整Tomcat的初始內(nèi)存和最大內(nèi)存需向JVM進行聲明，方法為在Windows系統(tǒng)下的文件{tomcat_home}/bin/catalina.bat，或是Linux下的文件{tomcat home}/bin/catalina.sh的前面，增加如下設置：

JAVA_OPTS=-Xms[初始化內(nèi)存大小]-Xmx[可以使用的最大內(nèi)存]

例如：JAVA一OPTS=-Xms1024m-Xmx2048m表示初始化內(nèi)存1024MB，可以使用的最大內(nèi)存為2048MB。

此外，還需要考慮到Java的垃圾回收機制。虛擬機的堆大小決定了虛擬機花費在垃圾回收上的時間和頻度。調整堆大小的目的是將垃圾收集的時間最小化，以在特定的時間內(nèi)處理請求的能力最大化。一般說來，使用物理內(nèi)存的80%作為堆大小是比較合適的。

3.1.2 修改Connector運行模式

Tomcat支持以下三種Connector運行模式：

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

（2）NIO（New I/O），是Java SE l.4及后續(xù)版本提供的一種較新的I/O操作方式（即Java.nio包及其子包）。Java.mo是一個基于緩沖區(qū)、并能提供非阻塞I/O操作的Java API，因此NIO也可看作是Non-blocking I/O的縮寫。該模式擁有比傳統(tǒng)I/O操作（BIO）更好的并發(fā)運行性能。

（3）APR（Apache Portable Runtime），即Apache HTTP服務器的支持庫。該模式下實現(xiàn)的是異步非阻塞，可以說是從操作系統(tǒng)層面解決I/O阻塞問題，因此運行性能也是三種模式中最好的。

可以看到，APR模式是在Tomcat服務器上運行大訪問量或高并發(fā)量應用系統(tǒng)的首選模式。但由于較早版本的Tomcat并不是默認支持該模式，需要額外安裝三個組件：APR庫、OpenSSL庫以及JNI wrappers for APR used by Tomcat（libtcnative），并將Tomcat安裝目錄下的server.xml文件中對應的Connector節(jié)點的protocol屬性值改為“org.apache.coyote.httpll.HttplIAprProtocol”才可啟用該模式。而從7.0.30版本Tomcat開始，已經(jīng)支持并默認在該模式下運行，因此我們可以選擇使用最新版本的Tomcat或是在舊版本上進行安裝配置。

3.2 數(shù)據(jù)庫調優(yōu)

MySQL是一款基于SQL的C/S模式關系型數(shù)據(jù)庫管理系統(tǒng)，是目前市面上最流行的通用數(shù)據(jù)庫管理系統(tǒng)之一，憑借其較好的可移植性，優(yōu)異的響應速度，高可靠性和安全性等特點得到了越來越多用戶的青睞。此外，MySQL作為一款開源的軟件，任何人員都可以免費獲得，而且其公開的源代碼和詳細的用戶手冊為數(shù)據(jù)庫技術的進一步優(yōu)化研究提供了便利，因此MySQL數(shù)據(jù)庫在中小型企業(yè)級的應用系統(tǒng)中被廣泛使用?？紤]到基站巡檢系統(tǒng)的基站巡檢數(shù)據(jù)量規(guī)模以及使用人員的訪問頻率，選用MySQL是極其合適的。

3.2.1 存儲引擎選擇

MySQL默認配置了多種存儲引擎，其類型主要有：MyISAM、InnoDB、NDB、Memory（HEAP）、Archive等。每一種類型，都有其各自特點，以下對各種常用的存儲引擎進行介紹與分析：

（l） MyISAM存儲引擎，特點是不支持事務，也不支持外鍵，但查詢速度較快，適合OLAP（Online Analytical Processing，聯(lián)機分析處理）應用。每個MyISAM表在磁盤上存儲成3個文件，其中文件名和表名都相同，擴展名分別為frm（存儲表定義）、MYD（MYData，存儲數(shù)據(jù)）和MYI（MYIndex，存儲索引）。MySQL-5.0版本之前，MyISAM默認支持的表大小僅為4G，從MySQL-5.0以后，默認支持256T的單表數(shù)據(jù)。此外，MyISAM只緩存索引數(shù)據(jù)。

（2）InnoDB存儲引擎，特點是支持外鍵、行鎖、非鎖定讀、從MySQL-4.1版本開始支持每個InnoDB引擎的表單獨放到一個表空間里。InnoDB通過使用MVCC（Multi-Version Concurrency Control，多版本并發(fā)控制）來獲取高并發(fā)性，并且實現(xiàn)SQL標準的4種隔離級別，并使用一種被稱成Next-Key Locking的策略來避免幻讀現(xiàn)象。除此之外InnoDB引擎還提供了插入緩存、二次寫、白適應哈希索引、預讀等高性能技術。

（3）NDB存儲引擎，特點是數(shù)據(jù)存放在內(nèi)存中，因此主鍵查找的速度極快，并且從MySQL-5.1版本開始可以將非索引數(shù)據(jù)放到磁盤上。NDB之前的缺陷是Join查詢是在MySQL數(shù)據(jù)庫層完成的，而不是在存儲引擎完成的，復雜的Join查詢需要巨大的網(wǎng)絡開銷，速度很慢。好在從MySQL cluster7.2版本開始此問題已經(jīng)被解決，Join查詢效率提高了近百倍。

（4）Memory存儲引擎，同樣會將數(shù)據(jù)放到內(nèi)存中，默認使用Hash索引，不支持TEXT和BLOB類型，并且varchar是按照char的方式來存儲的。MySQL數(shù)據(jù)庫在使用Memory存儲引擎作為臨時表存儲中間結果集時，如果中間集結果大于Memory表的容量設置，又或者中間結果集包含TEXT和BLOB列類型字段，MySQL會把它們轉換為MyISAM存儲引擎表而放到磁盤上，因此會對查詢產(chǎn)生較大的性能影響。

（5）Archive存儲引擎，特點是只支持Select和Insert操作，但插入速度較為高效而對查詢的支持相對較差，從MySQL-5.1版本開始支持索引，壓縮能力較強，非常適合存儲大量的、獨立的、作為歷史記錄存儲而不經(jīng)常被讀取的數(shù)據(jù)，因此主要用于歸檔數(shù)據(jù)的存儲。

可以看到，不同的存儲引擎，其特點及應用場景各不相同。在基站巡檢系統(tǒng)中，類似員工信息表以及基站信息表等此類表中的數(shù)據(jù)都較為固定，添加新數(shù)據(jù)或者對原有數(shù)據(jù)進行修改的情況遠少于讀取已有數(shù)據(jù)，即對該類數(shù)據(jù)表的的訪問中，查詢的比率遠大于插入、修改或刪除，因此對該類表的查詢速度是我們最為關心的。綜合考慮各引擎的特點，選用MyISAM是較為合適的。

而對于巡檢記錄表以及異常信息統(tǒng)計表等存放每次基站巡檢具體結果的數(shù)據(jù)表，主要的操作會是插入與讀取數(shù)據(jù)，而且存在對同一個表并發(fā)訪問的可能性，此時訪問速度將不再是我們最為關心的方面，應從事務安全等角度綜合考慮數(shù)據(jù)表的引擎選擇問題。綜合分析各引擎的特點，此類表選用InnoDB是較為合理的。

由于從MySQL-5.5.5版本開始，InnoDB被選作為MySQL的默認存儲引擎，因此在創(chuàng)建新表時，若未加特殊說明，該表的存儲引擎都將默認選擇InnoDB。如需更改數(shù)據(jù)表的存儲引擎，可通過以下兩種方式：一是選用數(shù)據(jù)庫管理工具，通過修改表屬性中的“存儲引擎”一項來進行更改；二是在MySQL白帶的命令行工具下通過輸入命令來更改，例如欲修改數(shù)據(jù)表table 1的存儲引擎為MyISAM，則在命令行工具中輸入命令“alter table table_l engine=MyISAM；”即可。

3.2.2 合理使用索引

索引是存儲引擎用于快速找到在某列中有特定值的記錄的一種數(shù)據(jù)結構。在不使用索引的情況下，MySQL必須從第1條記錄開始依次向后掃描整個表直到找出相關的行。表的數(shù)據(jù)量越大，花費時間越多。但如果表中查詢的列上設有索引，MySQL能快速定位到一個位置并進入到數(shù)據(jù)表文件中去搜尋，而沒有必要再查找所有數(shù)據(jù)。因此，索引將會對表的查詢速度有極大提升。

需要強調的是，索引的建立方式是否適當是影響數(shù)據(jù)庫性能的關鍵所在，創(chuàng)建索引也并非在所有情況下都是最好的解決方案?？偟膩碚f，只有當索引在幫助存儲引擎快速查找到記錄上帶來的提升遠大于其本身造成的額外開銷時，索引才可以稱得上是有效的。對于非常小的數(shù)據(jù)表，大部分情況下簡單的全表掃描更為直接、高效，因此不建議額外添加索引；而對于中到大型的表，索引對效率的提升將會非常明顯；但是對于特大型的表，建立和使用索引的代價將急劇增長。這種情況下，創(chuàng)建索引對于提升查詢速度的幫助是極小的，而且對于海量級別的數(shù)據(jù)，僅僅定位單條記錄意義已不大，通常都會使用區(qū)塊級別元數(shù)據(jù)來替代索引技術，此時應該轉為重點考慮分區(qū)技術。

此外，添加索引應遵從以下幾個原則：

（l）添加索引的列，應該是經(jīng)常出現(xiàn)在“where語句”中或是“order by”、“group by”之后的過濾條件中的字段，并根據(jù)實際情況選用合適的索引種類；

（2）在聯(lián)合查詢或子查詢等多表操作時的關連字段建議添加索引；

（3）選擇在某列添加索引時，應充分考慮該列中值的分布。對于數(shù)據(jù)均為惟一值的列，索引的效果最好，而具有多個重復值的列，索引效果則會較差。

（4）不要認為索引是“越多越好”，每添加一個索引都要占用額外的存儲空間，并降低寫操作的性能。在修改表的內(nèi)容時，索引必須進行更新，有時甚至需要重構，因此，索引越多，花費的時間會越長。如果創(chuàng)建了一個很少利用或從不使用的索引，那么會不必要地拖慢表的修改速度。此外，創(chuàng)建多余的索引也會給查詢優(yōu)化帶來了更多的工作。索引太多，有可能會使MySQL選擇不到所應使用的最好索引。只保持所需的最少索引有利于提高查詢效率。

3.3 其它相關技術優(yōu)化

3.3.1 使用Ajax優(yōu)化頁面顯示

傳統(tǒng)的Web頁面訪問采用同步交互模式，由客戶端向服務器端發(fā)送請求，服務器接到請求后進行一系列的處理后再把結果返回到客戶端。在服務器處理的整個過程中，客戶端必須等待，直到獲取服務器的響應數(shù)據(jù)后才能進行后續(xù)的處理，個別情況下還可能需要再次發(fā)送新的請求并繼續(xù)等待響應。如果交互的數(shù)據(jù)量較小，則此種交互模式可能不會暴露出太多問題，然而一旦交互數(shù)據(jù)量變大，服務器端的待處理業(yè)務一多，響應時間就會變長，顯示在瀏覽器中的將會是一片空白。此外，某些情況下為了更新頁面中的部分數(shù)據(jù)，卻不得不對整個頁面進行刷新。顯然，這種處理方式帶來的是極差的用戶體驗。對于這類問題，我們可以通過利用Ajax技術得到很好的解決方法。

Ajax是使用JavaScript與Web服務器完成數(shù)據(jù)交換的應用開發(fā)技術，本質上是對一組現(xiàn)有技術的無縫整合，其技術實現(xiàn)的核心是XMLHttpRequest對象，可使用該對象在JavaScript腳本中來實現(xiàn)對服務器的異步請求，在不重載頁面的情況下與服務器交換據(jù)而不用阻塞用戶。

Ajax模式的優(yōu)勢有以下幾方面：（l）帶來更好的用戶體驗，更新頁面無需刷新，減少用戶的等待時間；（2）“按需取數(shù)據(jù)”，可以最大程度地減少冗余請求，避免冗余數(shù)據(jù)的傳輸，最大程度的提高帶寬利用率；（3）可以把原本由服務器擔負的工作轉移到客戶端，利用客戶端的閑置能力來完成處理，減輕服務器端壓力；（4）可以靈活調用外部數(shù)據(jù)，增加了頁面顯示的多樣性。

在基站巡檢系統(tǒng)中，Ajax技術可在以下方面帶來提升：（1）數(shù)據(jù)校驗。在需要用戶進行輸入的場景下，可通過異步方式對數(shù)據(jù)提前進行校驗或是查重等工作，并且動態(tài)地顯示返回的結果信息，無需等到表單提交后才獲得處理結果，提供了良好的用戶體驗。（2）動態(tài)獲取數(shù)據(jù)。在需要用戶進行選項選擇的場景下，當用戶選擇某級節(jié)點后，只把對應分類的下一級數(shù)據(jù)讀取并顯示，每次按用戶需要動態(tài)獲得數(shù)據(jù)，避免冗余，提高資源利用率并且大大縮短用戶的等待時間。

3.3.2 使用數(shù)據(jù)庫連接池

通常情況下，直接使用JDBC調用數(shù)據(jù)庫即可滿足一個小型應用系統(tǒng)的要求，但是當用戶量較大或訪問頻度較高的情況下，就會出現(xiàn)因數(shù)據(jù)庫的訪問量突增而嚴重拖累服務器的現(xiàn)象。為了解決這一性能問題，可選擇使用數(shù)據(jù)庫連接池作為一個緩存的方式解決。

每次數(shù)據(jù)庫連接的建立都是一件既消耗系統(tǒng)內(nèi)存又耗費時間的工作，而使用連接池，則可預先建立連接。當應用程序需要使用時，就從連接池中直接獲取一個連接使用，應用程序使用完畢后，通過closeO方法即可將連接歸還到連接池。若并發(fā)增加，連接池會不斷的自動創(chuàng)建新連接以滿足調用需求，直到達到連接池的最大數(shù)目；當連接減少甚至沒有時，連接池會自動關閉一些，保持最小數(shù)目的連接。因此連接池的使用節(jié)省了連接建立開銷，消除了數(shù)據(jù)庫頻繁連接帶來的性能影響。

目前流行的常用連接池包括DBCP、C3PO、Proxool、Druid等。其中由阿里巴巴研發(fā)的Druid是目前最好的數(shù)據(jù)庫連接池，在功能、性能、擴展性等方面，都超過其他數(shù)據(jù)庫連接池，因此，在基站巡檢系統(tǒng)中選擇使用Druid。

4 結論

基于J2EE及相關技術的WEB應用系統(tǒng)的性能優(yōu)化并非一件簡單的事，必須在充分了解J2EE體系架構及各類相關技術自身特點的基礎上，結合系統(tǒng)所應用于的領域下的行業(yè)特點，從設計層面上對性能問題進行全面考慮、綜合分析，才能提出切實可行、效果顯著的優(yōu)化方案。本文所提出方案中的各項優(yōu)化策略，均已應用到基站巡檢系統(tǒng)的開發(fā)改進中，結合實際應用情況來看，系統(tǒng)運行效果較好，用戶滿意度較高。