關(guān)于計算機系統(tǒng)分析員論文
我所在的單位是把目標定位于金融領(lǐng)域開發(fā)IT應(yīng)用的一家信息技術(shù)公司。隨著金融電子化建設(shè)的發(fā)展和商業(yè)銀行之間市場競爭的加劇，各主要商業(yè)銀行不斷通過信息技術(shù)提供新的金融產(chǎn)品，并且希望能整合市場渠道。比如主要的商業(yè)銀行不斷推出形形色色的網(wǎng)上銀行服務(wù)。在這種背景下，本人參與了開發(fā)新一代網(wǎng)上銀行產(chǎn)品，涉及到提供網(wǎng)上個人理財服務(wù)、網(wǎng)上外匯買賣服務(wù)、網(wǎng)上企業(yè)服務(wù)等具有市場競爭力的產(chǎn)品。作為項目開發(fā)的組織者之一和主要的技術(shù)骨干，在整個項目開發(fā)過程中始終要處于第一線，從而在改進Web服務(wù)器性能、提高整個網(wǎng)上平臺系統(tǒng)性能方面收獲良多，在本文中簡要討論如下，希望與讀者們共享經(jīng)驗。在Web服務(wù)器配置與優(yōu)化方面，我有如下幾方面主要的體會：
第一方面是Web服務(wù)器選型考慮。
在Web服務(wù)器選型及網(wǎng)上平臺搭建之初，我們就已充分考慮整個網(wǎng)上平臺的性能及可擴展性問題。這一考慮為該系統(tǒng)的穩(wěn)定性及擴展性能力方面打下了堅實的基礎(chǔ)。
某銀行原有的一些網(wǎng)上產(chǎn)品由于開發(fā)較早，故而采用的是老式的HTTP Server+CGI程序調(diào)用的方式。這時，每一客戶請求需要對應(yīng)于后端系統(tǒng)的系統(tǒng)進程來運行CGI程序來處理，系統(tǒng)的開銷相當(dāng)大，系統(tǒng)的擴展能力也很差，性能已不能滿足業(yè)務(wù)處理的需要，故而在為此銀行系統(tǒng)具體選型的時候，我們一開始就否決了這種方案。
通過市場上同類產(chǎn)品的比較選擇，我們選擇了國際商業(yè)機器有限公司IBM的Web Sphere產(chǎn)品系列作為該行網(wǎng)上銀行系統(tǒng)的建立平臺。作出這樣選擇是因為Web Sphere基于使HTTP Server和應(yīng)用服務(wù)器相分離的整體架構(gòu)，同時支持JSP、Servlet和企業(yè)組Java Bean等輕量級線程規(guī)范，所有的請求對應(yīng)于應(yīng)用服務(wù)器上的處理線程，系統(tǒng)的開銷低、效率非常高，同時Web Sphere整個體系結(jié)構(gòu)相當(dāng)?shù)撵`活，為適應(yīng)擴展需要可以作不同的橫向和縱向擴展，從而可以滿足各銀行未來的擴展需要。
正是因為在一開始選型的時候我們就已考慮到未來的擴展需要，整個系統(tǒng)在接下來的幾次性能改進方面，我們大體上都能相對順利地達到了預(yù)期目標。
第二方面是Web服務(wù)器的性能配置。
在一開始系統(tǒng)上線的時候，由于系統(tǒng)的負荷不是很大，為了節(jié)省系統(tǒng)總擁有成本TCO投資，我們在一臺較低配置的IBM RS6000上投產(chǎn)了該系統(tǒng)。整個系統(tǒng)的HTTP服務(wù)器、應(yīng)用服務(wù)器、通信服務(wù)器等均位于該臺機器上，由于初始投產(chǎn)時用戶不多，所以系統(tǒng)的性能基本上能令人接受。
但隨著業(yè)務(wù)的發(fā)展和用戶訪問量的增大，我們發(fā)現(xiàn)該服務(wù)器的響應(yīng)變慢，系統(tǒng)的CPU利用率和內(nèi)外存交換顯著增大。經(jīng)過跟蹤，我們發(fā)現(xiàn)關(guān)鍵原因之一是系統(tǒng)的內(nèi)存不足的緣故。由于網(wǎng)上服務(wù)器把大量用戶的會話信息保存在內(nèi)存中供給應(yīng)用系統(tǒng)使用，當(dāng)內(nèi)存不足時，大量Session信息被迫交換至硬盤，大量CPU時間消耗在等候內(nèi)外存的交換上，系統(tǒng)效率迅速下降。
鑒于這種情況，我們把該服務(wù)器的內(nèi)存由2GB擴充為4GB，同時相應(yīng)調(diào)整用戶會話信息的保存時間，這樣整個系統(tǒng)的效率又回到較為理想的狀況。
由于新應(yīng)用的不斷投產(chǎn)及數(shù)據(jù)庫操作的日益增加，我們后來逐漸監(jiān)控到系統(tǒng)的數(shù)據(jù)庫處于繁忙狀態(tài)，系統(tǒng)的錯誤日志也記錄下了供應(yīng)用服務(wù)器使用的數(shù)據(jù)庫連接處出現(xiàn)資源不足的情況。在這種背景下，我們認為整個系統(tǒng)由于硬件配置所限，應(yīng)該進行橫向擴展，因此我們把數(shù)據(jù)庫服務(wù)器分離出來，配置到另一較高性能的服務(wù)器上，相應(yīng)定義的數(shù)據(jù)庫資源也大幅增加，這樣整個系統(tǒng)的性能又處于較為理想的狀況。
第三方面是對應(yīng)用系統(tǒng)進行相應(yīng)的優(yōu)化以提高性能。
Web服務(wù)器配置及相應(yīng)的硬件擴展不失為解決系統(tǒng)性能問題的一條捷徑，但應(yīng)用系統(tǒng)的優(yōu)化也是應(yīng)該重點加以考慮的，畢竟它能夠在投入較少的情況下提高系統(tǒng)的運用效率。
在開發(fā)的初期，我們就已經(jīng)十分注意系統(tǒng)的利用效率，比如提醒程序員盡量不要利用用戶會話信息(Session）來傳遞大的對象，對于內(nèi)存要注意回收等。同時，通過內(nèi)部的交流會推廣與介紹一些小的、有用的編程技巧來提高開發(fā)人員的水平，通過代碼的抽查，希望能在早期就發(fā)現(xiàn)問題等。
在系統(tǒng)運行期間，我們通過監(jiān)控發(fā)現(xiàn)，應(yīng)用服務(wù)器所基于的Java虛擬機，其內(nèi)存堆的空閑空間有不斷下降的趨勢，每隔若干天導(dǎo)致空間消耗殆盡、無法分配新對象空間，從而導(dǎo)致系統(tǒng)重啟。在排除了系統(tǒng)本身問題的原因外，我們確定為應(yīng)用系統(tǒng)的開發(fā)有問題。通過從網(wǎng)上萬載IBM公司檢測Java虛擬機的相關(guān)工具對JVM進行監(jiān)控后終于發(fā)現(xiàn)系統(tǒng)內(nèi)部存在著不能回收內(nèi)存的對象，再通過查找相應(yīng)的程序發(fā)現(xiàn)在該程序中有“環(huán)狀”的對象引用，從而導(dǎo)致對象使用后不能被垃圾收集器所回收。這個問題的解決過程雖然十分艱苦，但由于該問題不能通過升級硬件或增加資源配置而得到根本解決，會給系統(tǒng)帶來很大的隱患。所以，整個過程的分析與解決是完全值得的，更何況通過查找故障原因的過程，給整個項目組上了生動的一堂軟件質(zhì)量保證課，對項目組的質(zhì)量意識起了很大的促進作用。
所以說改進Web服務(wù)器的性能井不單純是系統(tǒng)管理方面的工作，它滲透到開發(fā)以及系統(tǒng)運行等一系列環(huán)節(jié)中。
第四方面預(yù)先考慮未來的擴展與性能需要。
隨著系統(tǒng)的發(fā)展及成熟，考慮到用戶訪問量的不斷上升，為了預(yù)留系統(tǒng)的發(fā)展空間，我們最近又對整個系統(tǒng)作了一個系統(tǒng)性的升級。通過引入多臺HTTP服務(wù)器及應(yīng)用服務(wù)器并行工作提高整個系統(tǒng)吞吐量及單點故障克服能力。由于在一開始選型的時候就已經(jīng)充分考慮到動態(tài)負載均衡及橫向擴展方面的需要，這一項的升級無需對整個系統(tǒng)的體系結(jié)構(gòu)作根本的變革，對應(yīng)用程序來說，更是沒有造成任何影響。
整個項目歷時近兩年，從這兩年的系統(tǒng)情況來看，整個系統(tǒng)是成功的。根據(jù)我親身的經(jīng)歷，系統(tǒng)性能并不單純是系統(tǒng)運行與管理階段的問題，而是滲透在項目論證、開發(fā)以及運行的各個階段。只有在各個階段都能充分考慮性能方面的需要，在實際運行時，整個系統(tǒng)的性能才可能真正有保障。在技術(shù)方面來看，可以綜合利用選型評估、硬件擴展、應(yīng)用優(yōu)化和系統(tǒng)配置優(yōu)化等一系列的手段；比如在硬件擴展方面，又可以分為主要部件擴容，縱向升級、橫向升級等方面。在我們的項目實踐中，曾綜合地利用了上述的各種手段。比如某銀行的整個系統(tǒng)從日訪問量不足1萬至現(xiàn)在的每日超過I0萬次以上的點擊的發(fā)展情況來看，整個系統(tǒng)的性能保障及提高方案是比較成功的。
【計算機系統(tǒng)分析員論文】相關(guān)文章：
工業(yè)控制的常規(guī)應(yīng)用-計算機系統(tǒng)分析員論文12-04
寫計算機論文11-15
計算機論文題目11-15
管理措施計算機維護論文論文11-13
網(wǎng)絡(luò)計算機安全論文02-26
計算機信息安全論文02-11
計算機英語論文03-13
計算機畢業(yè)論文05-17
計算機病毒論文06-20