張永華

（中國移動通信集團(tuán)公司廣西分公司 南寧530022）

1 引言

近年來，隨著電信運(yùn)營商市場的發(fā)展，為適應(yīng)全業(yè)務(wù)發(fā)展和市場競爭需要，對運(yùn)維管理系統(tǒng)能力提升提出了更高的要求，運(yùn)維管理系統(tǒng)經(jīng)過長期建設(shè)，各種應(yīng)用規(guī)模越來越龐大，所承載的應(yīng)用范圍不斷拓寬，其中電子運(yùn)維系統(tǒng)（electric operation maintenance system，EOMS）作為業(yè)務(wù)開通和網(wǎng)絡(luò)運(yùn)維集中管理的重要支撐系統(tǒng)，隨著用戶量的不斷擴(kuò)大，新功能模塊的更新上線，其性能開始下降，影響了用戶使用感知。EOMS采用基于中間件的Web應(yīng)用模式建設(shè)，這種分布式體系具有易擴(kuò)展和方便維護(hù)的特點(diǎn)，但其多層的體系架構(gòu)也給整體性能優(yōu)化帶來了新的問題與挑戰(zhàn)，以往對這種Web應(yīng)用性能優(yōu)化研究主要集中在數(shù)據(jù)庫訪問的性能優(yōu)化上，并沒有從整個體系考慮系統(tǒng)的性能優(yōu)化策略。針對這一問題，本文以EOMS系統(tǒng)的性能優(yōu)化實(shí)踐為背景，在保持系統(tǒng)良好體系結(jié)構(gòu)和易于擴(kuò)展、維護(hù)的基礎(chǔ)上，從主機(jī)系統(tǒng)、網(wǎng)絡(luò)、數(shù)據(jù)庫、中間件、應(yīng)用結(jié)構(gòu)多個層面對基于中間件的Web應(yīng)用提出性能優(yōu)化方法，并對這些方法的實(shí)施效果作了測試比較。

參照EOMS系統(tǒng)用戶數(shù)量在廣西省與中國移動通信集團(tuán)公司廣西分公司（簡稱廣西移動）同等規(guī)模的公司系統(tǒng)運(yùn)行情況，同時結(jié)合廣西省網(wǎng)絡(luò)現(xiàn)狀，將本次優(yōu)化活動的目標(biāo)設(shè)定如下：將EOMS系統(tǒng)日常處理訪問量最大的模塊——流程管理模塊下的工單處理速度作為本次優(yōu)化效果評估的主要指標(biāo)，最終把EOMS工單處理時間縮短到7 s以內(nèi)（當(dāng)前性能13 s）。

2 技術(shù)特點(diǎn)及性能影響因素

EOMS是一套支撐網(wǎng)絡(luò)運(yùn)維工作集中化、流程化、電子化、自動化、智能化的系統(tǒng)。廣西移動的EOMS由2006年開始建設(shè)，經(jīng)過4年多不斷的完善，目前系統(tǒng)主要分為流程管理、值班管理、業(yè)務(wù)開通、信息發(fā)布、代維管理、作業(yè)計(jì)劃等6大模塊。系統(tǒng)在用賬號已經(jīng)達(dá)到2 400個，日均在線人數(shù)600～700人，日均工單流轉(zhuǎn)量達(dá)到7 000～10 000張。隨著電信市場全業(yè)務(wù)的發(fā)展，EOMS將成為支撐全業(yè)務(wù)開通及保障的重要系統(tǒng)。

EOMS采用基于中間件的3層軟件結(jié)構(gòu)體系，自下而上分別是數(shù)據(jù)庫、中間件、Web服務(wù)（如圖1所示），這種架構(gòu)應(yīng)用本身不具備獨(dú)立運(yùn)行的能力，必須將其部署到中間件容器中，應(yīng)用系統(tǒng)才可以正常地運(yùn)行。隨著EOMS用戶量的增加，用戶經(jīng)常抱怨常用的應(yīng)用模塊（如工單、維護(hù)作業(yè)、信息發(fā)布等）訪問速度慢、頁面提交處理及查詢反應(yīng)時間長等問題。EOMS性能優(yōu)化必須結(jié)合系統(tǒng)的技術(shù)特點(diǎn)，對影響性能的各層面因素（包括主機(jī)系統(tǒng)、數(shù)據(jù)庫、中間件（應(yīng)用服務(wù)器）、應(yīng)用（服務(wù)層與應(yīng)用層）自身）進(jìn)行全面分析。以下分別從主機(jī)、數(shù)據(jù)庫、Web中間件、應(yīng)用4個層面，對可能存在的性能影響因素與影響特性進(jìn)行闡述。

2.1 主機(jī)系統(tǒng)

目前EOMS系統(tǒng)采用SPARC Enterprise M9000服務(wù)器。該型號服務(wù)器的性能有如下特點(diǎn)。

SPARC Enterprise M9000服務(wù)器是采用對稱式多處理（symmetric multi-processing，SMP）體系結(jié)構(gòu)開發(fā)的 Unix 服務(wù)器，兼具超級計(jì)算機(jī)的高速技術(shù)和 Unix服務(wù)器的開放性。如果在運(yùn)行過程中發(fā)生了問題，可以自我修正或隔離導(dǎo)致異常的環(huán)節(jié)，而無需停止系統(tǒng)。此特性可在許多情況下最大限度地減少系統(tǒng)故障，從而提高作業(yè)的連續(xù)性。

每個SPARC Enterprise M9000服務(wù)器都包含一個或多個SPARC64TMⅥ/SPARC64TMⅦCPU。它們可像多個服務(wù)器一樣運(yùn)行，允許靈活地使用資源（包括更有效地執(zhí)行作業(yè)操作），有利于虛擬化技術(shù)的應(yīng)用。針對M9000服務(wù)器可分區(qū)分片利用的新特性，結(jié)合EOMS應(yīng)用特性，可通過配置多個應(yīng)用節(jié)點(diǎn)且分布式部署的方式，使系統(tǒng)的資源利用率達(dá)到最優(yōu)。

另外，主機(jī)操作系統(tǒng)版本為Sun Solaris 10，其影響I/O性能的主要參數(shù)介紹如下。

（1）ulimit

ulimit是一種 Solaris系統(tǒng)的內(nèi)鍵功能，具有一套參數(shù)集，用于由它生成的 shell進(jìn)程及其子進(jìn)程的資源使用設(shè)置限制。

假設(shè)有這樣一種情況，一臺 Unix主機(jī)上同時登錄了10個人，在系統(tǒng)資源無限制的情況下，這 10個用戶同時打開了 500個文檔，而假設(shè)每個文檔的大小有 10 MB，這時系統(tǒng)的內(nèi)存資源就會受到巨大的挑戰(zhàn)。

而EOMS實(shí)際應(yīng)用的環(huán)境要比這種假設(shè)復(fù)雜得多，EOMS作為在線式數(shù)據(jù)庫處理應(yīng)用，對操作系統(tǒng)的文件資源操作更為頻繁，例如一個典型工單流操作中，每個工單文件流轉(zhuǎn)環(huán)節(jié)、步驟都對開啟文件描述符的數(shù)量、分配堆棧的大小、CPU時間、虛擬內(nèi)存大小等有非常嚴(yán)格的要求。資源的合理限制和分配，不僅僅是保證系統(tǒng)可用性的必要條件，也與系統(tǒng)上軟件運(yùn)行的性能有著密不可分的聯(lián)系。這時，ulimit可以起到很大的作用，是一種簡單并且有效的實(shí)現(xiàn)資源限制的方式。

ulimit用于限制 shell啟動進(jìn)程所占用的資源，支持對以下各種類型資源的限制：所創(chuàng)建的內(nèi)核文件的大小、進(jìn)程數(shù)據(jù)塊的大小、shell進(jìn)程創(chuàng)建文件的大小、內(nèi)存鎖住的大小、常駐內(nèi)存集的大小、打開文件描述符的數(shù)量、最大分配堆棧的大小、CPU時間、單個用戶的最大線程數(shù)、shell進(jìn)程所能使用的最大虛擬內(nèi)存。同時，它支持硬資源和軟資源的限制。

（2）TCP_TIME_WAIT_INTERVAL

該參數(shù)用于通知TCP/IP將已關(guān)閉的連接控制塊保留的時間。在應(yīng)用程序完成 TCP/IP連接后，控制塊將保留指定的時間。當(dāng)連接比率較高時，該保留時間的設(shè)置可能導(dǎo)致累積大量的 TCP/IP連接，從而導(dǎo)致服務(wù)器性能下降。當(dāng)EOMS系統(tǒng)在線用戶并發(fā)處理統(tǒng)一應(yīng)用模塊（如維護(hù)作業(yè)模塊）時，服務(wù)器在某些峰值期間會延遲，用netstat命令顯示 HTTP Server打開的許多套接字處于 CLOSE_WAIT或 FIN_WAIT_2狀態(tài)。明顯的延遲可能會長達(dá) 4 min，其間服務(wù)器無法發(fā)送任何響應(yīng)，但是 CPU利用率很高，所有活動都在系統(tǒng)進(jìn)程中。

（3）TCP_FIN_WAIT_2_FLUSH_INTERVAL

該參數(shù)用于指定禁止處于 FIN_WAIT_2狀態(tài)的連接保持該狀態(tài)的計(jì)時器時間間隔。該參數(shù)與TCP_TIME_WAIT_INTERVAL配合使用，可以讓EOMS的數(shù)據(jù)操作應(yīng)用訪問操作系統(tǒng)時，網(wǎng)絡(luò)等待時間達(dá)到合理水平。

2.2 數(shù)據(jù)庫

數(shù)據(jù)庫常用的幾種定量分析方法主要包括：響應(yīng)時間和吞吐量之間的權(quán)衡、數(shù)據(jù)庫的可用性和命中率、內(nèi)存的使用情況。

（1）響應(yīng)時間和吞吐量之間的權(quán)衡

響應(yīng)時間是指應(yīng)用做出反應(yīng)的時間，以毫秒或秒表示，該值越低越好。吞吐量是指每個單位時間完成的工作，或是單位時間內(nèi)數(shù)據(jù)庫完成的 SQL語句數(shù)目，以每秒的事務(wù)量表示，該值越高越好。

（2）數(shù)據(jù)庫的高可用性和命中率

高可用性：數(shù)據(jù)庫系統(tǒng)保障能長時間運(yùn)行，減少計(jì)劃內(nèi)（甚至是計(jì)劃外）停機(jī)時間，最好能夠24 h×7無障礙運(yùn)行，這就是高可用性標(biāo)準(zhǔn)。

命中率：Oracle數(shù)據(jù)庫通過使用LRU算法，將最近訪問的數(shù)據(jù)塊存放到緩存中，從而使對磁盤數(shù)據(jù)的訪問效率優(yōu)化到接近內(nèi)存訪問的速度。由于數(shù)據(jù)庫應(yīng)用的核心操作就是數(shù)據(jù)的訪問和處理，因此如果應(yīng)用系統(tǒng)訪問的大部分?jǐn)?shù)據(jù)塊已在緩存中，也就是數(shù)據(jù)在緩存中命中，即數(shù)據(jù)命中率。

（3）內(nèi)存分配調(diào)優(yōu)

內(nèi)存分配是在系統(tǒng)運(yùn)行期間動態(tài)完成的，以EOMS的Oracle 10版本為例，數(shù)據(jù)庫管理員可以根據(jù)數(shù)據(jù)庫運(yùn)行狀況調(diào)整數(shù)據(jù)庫系統(tǒng)全局區(qū)（SGA區(qū)）的數(shù)據(jù)緩沖區(qū)、日志緩沖區(qū)和共享池的大??；還可以調(diào)整程序全局區(qū)（PGA區(qū)）的大小。合理地分配SGA與PGA內(nèi)存，可以提高緩存的性能，降低 SQL語句解析的時間，減少頁面調(diào)度及換頁，另外一方面，數(shù)據(jù)庫索引配置不合理，會導(dǎo)致Oracle數(shù)據(jù)庫產(chǎn)生大量的全表掃描，全表掃描必然造成數(shù)據(jù)內(nèi)存頁面的頻繁調(diào)度。

本文中的EOMS系統(tǒng)優(yōu)化，將重點(diǎn)從數(shù)據(jù)庫的可用性和命中率、內(nèi)存的使用情況兩個方面進(jìn)行分析。

2.3 中間件

中間件是一種獨(dú)立的系統(tǒng)軟件或服務(wù)程序，分布式應(yīng)用軟件借助這種軟件在不同的技術(shù)之間共享資源。中間件位于客戶機(jī)/服務(wù)器的操作系統(tǒng)之上，管理計(jì)算機(jī)資源和網(wǎng)絡(luò)通信，是連接兩個獨(dú)立應(yīng)用程序或獨(dú)立系統(tǒng)的軟件。相連接的系統(tǒng)，即使具有不同的接口，通過中間件彼此也能交換信息。

EOMS采用的是IBM WebSphere Process Server V6（WPS）中間件產(chǎn)品，WPS是運(yùn)行于 WebSphere ApplicationServer(WAS)之上的業(yè)務(wù)流程集成服務(wù)，WAS中的各種參數(shù)的設(shè)置都會對 WPS的運(yùn)行性能產(chǎn)生直接影響。影響WAS運(yùn)行性能的主要參數(shù)如下。

（1）追蹤和日志相關(guān)的參數(shù)

追蹤和日志是進(jìn)行問題分析最重要的手段之一，詳細(xì)的追蹤和日志可以幫助用戶和 WAS開發(fā)、支持人員獲得更多的運(yùn)行信息，但同時也帶來了較大的 I/O資源消耗，降低了 WAS的性能。

（2）Java虛擬機(jī) (JVM)相關(guān)的參數(shù)

其中aBn為集合Bn中元素的策略狀態(tài)，an0表示用戶n退出信道競爭時的策略狀態(tài)，aBn/n為用戶n的相鄰用戶在n退出信道競爭時的策略狀態(tài).然而博弈過程中，n只對集合In中的用戶產(chǎn)生干擾，則有：

IBM JVM默認(rèn)的 Java GC規(guī)則是標(biāo)記-清除-整理 ，IBM在Java 5.0之后引入新的 Java GC規(guī)則，該規(guī)則在許多情況下通過調(diào)整短生命周期對象和長生命周期對象所占用 Java堆的空間大小提高性能。初始堆大小用于指定JVM代碼可使用的初始堆大?。ㄒ哉鬃止?jié)計(jì)）。增加最小堆大小可改進(jìn)啟動，減少發(fā)生垃圾回收的次數(shù)，并且可實(shí)現(xiàn) 10%的性能增益。通常，增加 Java堆的大小會改進(jìn)吞吐量，直到堆不再駐留在物理內(nèi)存中。當(dāng)堆開始交換到磁盤后，Java性能將大幅下降。

（3）線程池大小相關(guān)的參數(shù)

對于每個WAS的Server，有3個線程池的參數(shù)需要調(diào)整：Default、ORB、Web Container。

Default線程池中的線程為分配給 MDB的實(shí)例使用，除非單獨(dú)指定其他的線程池。這意味著Default線程池要比較大，尤其是當(dāng)增大激活規(guī)范的 maxConccurency參數(shù)時。

ORB（object request broker，對象請求代理）線程池用于運(yùn)行 ORB請求，如遠(yuǎn)程 EJB（enterprise Java beans）調(diào)用。如果有大量的遠(yuǎn)程 EJB被調(diào)用，比如人工任務(wù) API被調(diào)用，需要加大 ORB線程池大小提高遠(yuǎn)程 EJB調(diào)用的并發(fā)處理能力。

Web Container線程池中的線程用于處理 HTTP和Web服務(wù)的請求，且被所有應(yīng)用共用，因此需要增大線程池，以提高 HTTP和 Web服務(wù)請求的并發(fā)處理能力。

（4）數(shù)據(jù)源連接池大小相關(guān)的參數(shù)

最大連接數(shù)指可以在數(shù)據(jù)源連接池中創(chuàng)建的最大物理連接數(shù)，最大連接數(shù)會影響數(shù)據(jù)庫操作的并發(fā)能力。

2.4 應(yīng)用程序

應(yīng)用不是獨(dú)立于它的操作環(huán)境而存在的，相反，內(nèi)存資源、磁盤輸入/輸出和 CPU的使用直接影響它的操作環(huán)境，應(yīng)用優(yōu)化得越好，就越容易優(yōu)化支持這個應(yīng)用的環(huán)境。由于其他系統(tǒng)硬件或軟件的原因而導(dǎo)致的瓶頸，如應(yīng)用系統(tǒng)本身的設(shè)計(jì)問題、超出系統(tǒng)吞吐量（在一定時間內(nèi)系統(tǒng)處理數(shù)據(jù)的能力）的限制、使用的 SQL結(jié)構(gòu)和語句不合理等，必須聯(lián)合應(yīng)用軟件開發(fā)商，從設(shè)計(jì)上分析影響性能的問題，并對其進(jìn)行改進(jìn)和調(diào)整。常見的問題如下。

·大量使用固定參數(shù)，SQL硬編碼過多。

·SQL語句中編碼不嚴(yán)謹(jǐn)，查詢條件設(shè)計(jì)不合理。

·頻繁和無序的邏輯數(shù)據(jù)塊讀寫，導(dǎo)致物理I/O的讀取次數(shù)過多。

·代碼關(guān)鍵字不合理，以“不等于”和“等于”為例：SQL中帶有很多“<>”的查詢，如果字段值是有限個不重復(fù)值，要改寫為多個OR連接的“=”查詢，例如deleted<>1，deleted字段只出現(xiàn)2個值，即 0和 1，不如寫為deleted=0，“<>”查詢會導(dǎo)致字段的索引失效，應(yīng)盡量避免。

3 優(yōu)化實(shí)施方法

3.1 操作系統(tǒng)參數(shù)調(diào)優(yōu)

（1）Solaris 文件描述符（ulimit）

文件描述符是Unix系統(tǒng)內(nèi)核中用于表示特定進(jìn)程打開的特定文件的方式，通常是一個整型的變量。如果此參數(shù)的值過低，在系統(tǒng)日志中顯示打開過多文件錯誤，從而影響用戶的請求。根據(jù)EOMS用戶訪問量和工單數(shù)據(jù)處理量的估算，對EOMS操作系統(tǒng)Solaris 10的相應(yīng)參數(shù)調(diào)整如下。

缺省值：無；

建議值：65 535。

（2）Solaris TCP_TIME_WAIT_INTERVAL

該參數(shù)是通知TCP/IP保留已關(guān)閉連接控制塊的時間。在應(yīng)用程序完成 TCP/IP連接后，控制塊保留指定的時間。根據(jù)EOMS數(shù)據(jù)連接方式和TCP網(wǎng)絡(luò)訪問特點(diǎn)，對EOMS操作系統(tǒng)Solaris 10的相應(yīng)參數(shù)調(diào)整如下。

缺省值：缺省為 2 400 s。

建議值：60 s。

（3）Solaris TCP_FIN_WAIT_2_FLUSH_INTERVAL

該參數(shù)指定禁止處于 FIN_WAIT_2中的連接保留在此狀態(tài)中的定時器間隔。根據(jù)EOMS數(shù)據(jù)連接方式和TCP網(wǎng)絡(luò)訪問特點(diǎn)，對EOMS操作系統(tǒng)Solaris 10的相應(yīng)參數(shù)調(diào)整如下。

缺省值：缺省為 675 000。

建議值：67 500。

EMOS系統(tǒng)的分布式部署方案如圖2所示。

EOMS系統(tǒng)，現(xiàn)有軟件部署架構(gòu)由一臺ISA服務(wù)器在最前端實(shí)現(xiàn)移動運(yùn)維內(nèi)部網(wǎng)絡(luò)與移動OA網(wǎng)絡(luò)間的互連互通。

在ISA服務(wù)器后端，引入一個HTTP服務(wù)中間件NGINX。NGINX起到負(fù)載均衡、按端口提供映射服務(wù)的作用。其優(yōu)點(diǎn)如下：由于系統(tǒng)實(shí)現(xiàn)分布式處理，以NGINX替換原IBM提供的負(fù)載分流軟件HIS以提高負(fù)載分流時的性能；通過NGINX配置文件的修改調(diào)整，當(dāng)系統(tǒng)某組節(jié)點(diǎn)出現(xiàn)故障時，可以快速切換，將使用用戶分流到其他節(jié)點(diǎn)。切換時間2 s，不影響用戶。

在NGINX服務(wù)器后端，通過NGINX和M9000虛擬化分區(qū)技術(shù)，對應(yīng)用中間件建立了7組節(jié)點(diǎn)服務(wù)。采用7組節(jié)點(diǎn)的原因如下：原有EOMS系統(tǒng)WPS軟件應(yīng)用集群只有兩個節(jié)點(diǎn)，兩個節(jié)點(diǎn)共同承載整個EOMS系統(tǒng)的所有應(yīng)用，當(dāng)EOMS軟件因?yàn)榫€程或者應(yīng)用高負(fù)荷導(dǎo)致系統(tǒng)崩潰時，無備用節(jié)點(diǎn)提供系統(tǒng)服務(wù)。

當(dāng)某個EOMS應(yīng)用內(nèi)部異常導(dǎo)致某個WPS節(jié)點(diǎn)崩潰時，通過NGINX配置快速切換，不會影響其他應(yīng)用資源，以保障應(yīng)用可用性和穩(wěn)定性。

EOMS系統(tǒng)既存在人工任務(wù)（如派發(fā)工單、處理工單等），也存在自動任務(wù)（如網(wǎng)管告警派單接口、各類輪循任務(wù)等）。由于人工任務(wù)與自動任務(wù)的特點(diǎn)及要求是不同的，如果混雜在一起，將會導(dǎo)致系統(tǒng)越在忙時越忙的情況，影響系統(tǒng)運(yùn)行。所以在新的系統(tǒng)環(huán)境中按照業(yè)務(wù)特點(diǎn)，對系統(tǒng)進(jìn)行拆分及分布式部署，使自動任務(wù)與人工任務(wù)相隔離，各行其道，互不干擾。

數(shù)據(jù)庫承載服務(wù)在原EOMS系統(tǒng)采用的HA技術(shù)上，引入了Oracle Data Guard同步備份機(jī)制，保證了在數(shù)據(jù)庫出現(xiàn)異常時，可以在線切換到備用的數(shù)據(jù)庫進(jìn)行業(yè)務(wù)承載，達(dá)到應(yīng)用24 h不間斷處理服務(wù)的目的。

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

本次結(jié)合EOMS日常工單處理量及人工任務(wù)并發(fā)訪問量，對數(shù)據(jù)庫進(jìn)行DBA跟蹤，主要對Hit Ratio、PGA、LOG buffer、Hash join語句等參數(shù)作出以下調(diào)整：

·因Hit Ratio命中率低，將db_cache_size增加到7 086 MB，同時 SGA_MAX_SIZE相應(yīng)增加，Hit Ratio調(diào)整前后指標(biāo)變化如圖3所示；

·因PGA的命中率極低，將pga_aggregate_target提高一倍后，數(shù)據(jù)庫TEMP表空間現(xiàn)象明顯減少，大幅增加了涉及sort和Hash join操作的語句執(zhí)行效率；

·因LOG buffer相關(guān)等待事件明顯，增大log_buffer大小為2 MB；

·按照順序掃描的SQL語句創(chuàng)建或重建相關(guān)表的索引；

·新增索引，對無索引或條件語句涉及的字段未建有索引的表創(chuàng)建相應(yīng)的索引，通過statspack篩選所有table access full的語句，判斷全表掃描的必要性，對于走索引合理的語句創(chuàng)建合適的索引，通過梳理新建了35個索引，調(diào)整后全表掃描前后的對比如圖4所示；

·把使用最頻繁的幾個索引單獨(dú)放在一個dbspace里，暫時不需要對單個索引作分片處理。

索引表空間分布如圖5所示。SYSTEM和XDB為系統(tǒng)索引表空間，indexdbs表空間是主要的用戶索引表空間，包含306個用戶索引，EOMS30和emosdbs是次要用戶索引表空間，分別包含184個和175個用戶索引。

3.3 中間件調(diào)優(yōu)

通過對IBM WebSphere的中間件運(yùn)行日志進(jìn)行跟蹤分析，結(jié)合IBM官網(wǎng)給出中間件性能問題指南手冊，重點(diǎn)對JVM、線程、數(shù)據(jù)庫連接池等方面進(jìn)行分析調(diào)優(yōu)。

（1）VM 檢查

目前系統(tǒng)分配給WPS JVM的大小為1 GB，在實(shí)際JVM消耗情況跟蹤中，發(fā)現(xiàn)系統(tǒng)運(yùn)行過程中，其JVM的峰值已經(jīng)與系統(tǒng)設(shè)定的閾值很接近了，在用戶請求集中而可用資源較少的情況下，就會出現(xiàn)系統(tǒng)等待的情況，原因是中間件必須將內(nèi)存回收后，才會分配排隊(duì)等待的請求，所以JVM要進(jìn)行適當(dāng)?shù)恼{(diào)整，把最大堆調(diào)整至1 500 MB。

（2）線程池

EOMS所有用戶訪問請求最終都轉(zhuǎn)化成中間件用戶響應(yīng)線程的形式完成處理，線程池解決了用戶響應(yīng)線程的創(chuàng)建與銷毀所消耗的時間，可以有效地提高對用戶請求的響應(yīng)，所以給線程池設(shè)置一個合適的值，滿足目前系統(tǒng)吞吐量是一個很重要的工作。目前系統(tǒng)分配給中間件的線程數(shù)是150個，即線程池中有150個線程循環(huán)響應(yīng)用戶的請求。結(jié)合系統(tǒng)設(shè)置和對忙時EOMS應(yīng)用日志的觀察，認(rèn)為需要增大線程池，以滿足現(xiàn)有的業(yè)務(wù)需求，因此將線程數(shù)設(shè)置為200個。

（3）數(shù)據(jù)庫連接池

EOMS應(yīng)用并不直接管理數(shù)據(jù)庫連接，而是通過中間件提供的連接池管理。在每次建立數(shù)據(jù)庫物理連接時，數(shù)據(jù)庫要為該連接分配多種資源，反之，釋放連接時，要把這些資源及時釋放掉。分配和釋放資源也都是耗時的操作，因此，反復(fù)建立/釋放數(shù)據(jù)庫連接會對系統(tǒng)的效率產(chǎn)生不良影響。IBM WebSphere自身提供連接池技術(shù)，在連接池中維護(hù)多個活動的數(shù)據(jù)庫物理連接，當(dāng)系統(tǒng)需要進(jìn)行數(shù)據(jù)庫訪問操作時，從池中獲得一個連接，操作完畢后并不直接釋放，而是把連接放回池中，以便以后使用，這樣可以大大減少建立/釋放連接的次數(shù)。通過對連接池物理連接數(shù)量大小的調(diào)整，可以獲得最佳性能。結(jié)合系統(tǒng)設(shè)置和EOMS忙時的應(yīng)用日志的觀察，需要相應(yīng)地對數(shù)據(jù)連接池參數(shù)進(jìn)行調(diào)整，經(jīng)過評估，250個足以滿足現(xiàn)有業(yè)務(wù)需求，因此連接池的最大并發(fā)數(shù)設(shè)置為250個。

3.4 應(yīng)用代碼調(diào)優(yōu)

完成以上3個層面的調(diào)整后，發(fā)現(xiàn)還有30%～40%的系統(tǒng)性能問題未得到明顯改善，需要進(jìn)一步對應(yīng)用代碼進(jìn)行分析。主要提出以下EOMS開發(fā)編碼規(guī)范，以“關(guān)鍵模塊代碼走查”和“框架代碼復(fù)查”為主要方式，對代碼提出了調(diào)整策略。

（1）批量查詢代碼調(diào)整策略

一次操作中提取盡量多的數(shù)據(jù) (N+1)：通過代碼循環(huán)優(yōu)化，增加一次性數(shù)據(jù)讀取的數(shù)量集合，減少與數(shù)據(jù)庫交互的次數(shù)，以便大量數(shù)據(jù)操作在內(nèi)存中完成，保證代碼執(zhí)行效率。

（2）將需要存取的塊的數(shù)量減到最小，必要時重寫代碼及SQL語句

即能定義為包體的局部過程或局部變量的，就不要在包中定義；能在過程內(nèi)定義的子過程或變量，就不要定義為包體中的局部過程或局部變量；子過程使用的變量，不要在父過程中定義。從而執(zhí)行部分縮小，減少網(wǎng)絡(luò)傳輸以及內(nèi)存交互的負(fù)荷。

（3）對關(guān)鍵字編碼進(jìn)行規(guī)范

規(guī)則如下。

·變量未賦值前，保持進(jìn)行Null的引用，避免因內(nèi)存泄露導(dǎo)致系統(tǒng)性能下降。

·減少SQL硬編碼，硬編碼即每個SQL查詢條件都使用固定參數(shù)形式寫死，這樣導(dǎo)致每一次參數(shù)的變動Oracle數(shù)據(jù)庫都會當(dāng)作一條新的SQL解析并執(zhí)行，無法利用Oracle的緩存命中區(qū)，從而增加了Oracle數(shù)據(jù)庫解析的開銷。

·不要隨意使用distinct、<>等關(guān)鍵字，如必須使用，注意分析其必要性。

·避免未捕獲的異常拋出，每個SQL都有可能出錯。需要使用異常捕獲語句包裹每個SQL，并給出恰當(dāng)?shù)奶崾?。比如某系統(tǒng)前段時間一直有no_data_found的錯誤，程序拋出的異常就是這個。很簡單，這說明程序中有個select語句查詢結(jié)果為空，但并沒有捕獲這個異常，所以直接拋出了no_data_found，這個錯誤是無法定位的。過多未被捕獲異常會產(chǎn)生額外的性能開銷。

通過程序代碼走查修改，逐步優(yōu)化程序代碼，減少不規(guī)范，從每周統(tǒng)計(jì)的同一類工單查詢的執(zhí)行效率趨勢圖，可以看出優(yōu)化效果明顯，如圖6所示。

4 優(yōu)化效果及貢獻(xiàn)度

（1）優(yōu)化效果

對EOMS訪問量最多的流程管理模塊下的工單處理模塊處理速度進(jìn)行優(yōu)化前后效果比對分析，優(yōu)化前后的對比趨勢如圖7所示。

經(jīng)過優(yōu)化，工單平均處理時間下降到7 s以下，性能效果較優(yōu)化前提升了50%。

（2）優(yōu)化任務(wù)貢獻(xiàn)度

根據(jù)優(yōu)化順序，針對主機(jī)系統(tǒng)、中間件、數(shù)據(jù)庫、應(yīng)用代碼4個方面，每做完一項(xiàng)優(yōu)化措施，對運(yùn)維系統(tǒng)的性能優(yōu)化效果提升貢獻(xiàn)情況進(jìn)行記錄和統(tǒng)計(jì)，詳見圖8。

可以看出，對于基于Web中間件的運(yùn)維系統(tǒng)調(diào)優(yōu)，建議的調(diào)優(yōu)任務(wù)的實(shí)施順序依次為：數(shù)據(jù)庫調(diào)優(yōu)、應(yīng)用代碼調(diào)優(yōu)、中間件調(diào)優(yōu)、主機(jī)系統(tǒng)調(diào)優(yōu)。

5 結(jié)束語

本文結(jié)合具體實(shí)踐，對基于中間件的Web應(yīng)用系統(tǒng)進(jìn)行性能調(diào)優(yōu)，從主機(jī)系統(tǒng)、中間件、數(shù)據(jù)庫、應(yīng)用結(jié)構(gòu)4方面提出了分析和優(yōu)化策略，并最終取得較好的成效。同時對各層面調(diào)優(yōu)實(shí)施后對整體優(yōu)化效果的貢獻(xiàn)情況進(jìn)行記錄與分析，為后續(xù)同類型技術(shù)架構(gòu)的運(yùn)維管理系統(tǒng)性能問題優(yōu)化提供了參考依據(jù)和優(yōu)化方向性指導(dǎo)。

1 中國移動通信集團(tuán)有限公司.中國移動電子運(yùn)維系統(tǒng)技術(shù)規(guī)范（第 3 版）,2009

2 郭海峰,陽國貴.Oracle數(shù)據(jù)庫性能調(diào)優(yōu)技術(shù)與實(shí)現(xiàn).計(jì)算機(jī)工程,2006(19)

3 孫磊.構(gòu)建高性能WebSphere企業(yè)級應(yīng)用.北京:電子工業(yè)出版社,2008

4 邢文英.QC小組基礎(chǔ)教材（修訂版）.北京:中國社會出版社,2005