基于Web中間件的運維管理系統(tǒng)的性能優(yōu)化方法研究與實踐

張永華

（中國移動通信集團公司廣西分公司 南寧530022）

1 引言

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

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

2 技術特點及性能影響因素

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

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

2.1 主機系統(tǒng)

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

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

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

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

（1）ulimit

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

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

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

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

（2）TCP_TIME_WAIT_INTERVAL

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

（3）TCP_FIN_WAIT_2_FLUSH_INTERVAL

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

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

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

（1）響應時間和吞吐量之間的權衡

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

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

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

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

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

內(nèi)存分配是在系統(tǒng)運行期間動態(tài)完成的，以EOMS的Oracle 10版本為例，數(shù)據(jù)庫管理員可以根據(jù)數(shù)據(jù)庫運行狀況調(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ù)庫索引配置不合理，會導致Oracle數(shù)據(jù)庫產(chǎn)生大量的全表掃描，全表掃描必然造成數(shù)據(jù)內(nèi)存頁面的頻繁調(diào)度。

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

2.3 中間件

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

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

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

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

（2）Java虛擬機 (JVM)相關的參數(shù)

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

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

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

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

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

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

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

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

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

2.4 應用程序

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

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

·SQL語句中編碼不嚴謹，查詢條件設計不合理。

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

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

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

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

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

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

缺省值：無；

建議值：65 535。

（2）Solaris TCP_TIME_WAIT_INTERVAL

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

缺省值：缺省為 675 000。

建議值：67 500。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（1）VM 檢查

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

（2）線程池

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

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

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

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

完成以上3個層面的調(diào)整后，發(fā)現(xiàn)還有30%～40%的系統(tǒng)性能問題未得到明顯改善，需要進一步對應用代碼進行分析。主要提出以下EOMS開發(fā)編碼規(guī)范，以“關鍵模塊代碼走查”和“框架代碼復查”為主要方式，對代碼提出了調(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)絡傳輸以及內(nèi)存交互的負荷。

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

規(guī)則如下。

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

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

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

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

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

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

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

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

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

（2）優(yōu)化任務貢獻度

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

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

5 結束語

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

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

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

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

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