性能調優

性能調優

性能調優是指為軟體提供較佳的性能,用於處理系統回響速度太慢等。

基本介紹

  • 中文名:性能調優
  • 含義:為軟體提供較佳的性能
  • 現象:系統回響速度太慢等
  • 基線: 調校前系統的各種數據
簡介,現象,目標,基線,支出,

簡介

什麼是性能調校呢?一般是當用戶抱怨“太慢了”、“性能不足”、“軟硬體需要升級了”等問題時,提供較佳的性能。但不是要解決用戶所說的“這系統毀了”、“它不會工作了”等問題,這可能需要的是備援回滾、提高系統可獲得性(HA high Availability)等解決方案。但就資料庫系統而言,規劃高可獲得性的架構(如SQL Cluster、Mirroring、Log Shipping、Replication等)不會提升系統性能,還要注意是否降低了性能。

現象

而一般觀測性能問題的現象有:
 系統回響速度太慢。
 每秒所完成的系統輸出/入低於預期。
 相同的環境,但每秒鐘所完成的批操作較先前少。
系統資源(如CPU、記憶體、硬碟或網路等)長時間處於耗盡的狀態。
通常調校的目標是以用戶的期望為依據,除非你的數學與信息基本功非常紮實,否則很難知道調校的極限在哪。因此,我們的目標往往是符合用戶的期盼即可

目標

這些落於紙上的目標應越明確越好,例如上述的情況,若目標是 “我想要調低記憶體的使用率,因為它的值太高了”就不如“我想要調低某個程式開始獲取記憶體的設定,因為它可能吃掉太多的記憶體,但實際沒有用到這么多,而其他的應用程式沒有足夠的記憶體,導致整體系統性能不佳”。後者的描述有目標,且可以比較,因為實際調整後可以觀察調低記憶體的程式執行起來是否有問題,整體的性能與沒調整前是否有差異。
除了以文檔描述基線、調校的目標外,還可以以文檔描述所用的工具,如評估性能的程式、真實應用程式的片段功能、各種資源的性能監視程式、壓力測試程式等。同時,有越詳細的步驟越好。性能調校可能是一再的錯誤嘗試,因為大部分的狀況都是撲朔迷離的,無法一眼看出問題所在,需要改改這個,看看是否比較好,再修修那個,看看結果如何。若沒有文檔記錄,你可能會在性能調校的大迷宮中打轉,做一些類似而重複的事情,但總理不出頭緒。
嘗試列出系統中各個組件合理的性能消耗,可以幫助你理清整個系統訪問中,各個組件所占的性能消耗比例,哪些部分有可以調整的空間。另外,再搭配調整該部分的成本有多高,讓你了解調整的優先權,並對系統的極限有更佳的認識。

基線

調校性能的第一個工作應該是建立性能的基線(baseline),所需的類型有:
 昔日系統正常運行時的數據。
 調校前系統的各種數據。
 用戶希望達到的目標。
基線是用來比較的,任何性能調校的動作都應該依憑數據,不要訴諸情緒。筆者常聽到工程師說“今天的性能感覺比較差了”或是“現在系統回響比較慢了”。這種話是我們要幫用戶解決問題的起因,但不應該是工程師講的話。人的感覺非常不準,可能是心情不好,可能是對工作不滿意,對系統的包容力就比較差,感覺就不好了。
系統回響比較慢,要知道正常是多少、慢了多少、時間差是多少、數據量多少、多少人同時上線、處理量多少等。也就是要有基線,有客觀的數據,這才有好的調校基礎。而通常筆者碰到的是:工程師與用戶們忙了一天,精疲力竭後,會安慰自己“性能比較好了”。
如前文所述,一般要將用戶的期待量化,例如,用戶可以接受系統的回響時間是3~5 秒。而用戶的期待通常是來自於以下方面。
工作需求:如一定要在某個時間點前完成,一秒之內要完成多少交易量才能滿足多人訪問等。以往系統的使用經驗。一些性能數據值(benchmark):不管是廠家提供的,還是業界提出的標準值。其他用戶使用類似功能的經驗。
為什麼討論這個呢?因為期待要合理。不要第一次開車開賓士,然後誤以為全世界的汽車開起來都要像這樣。或許你會覺得這不可能發生。但事實上,若以往的系統是以Windows Form為基礎,現在一模一樣的功能,但改為以Web Form為基礎,在相同的硬體上,可能回響就比較慢。畢竟以往從SQL Server或COM+/MTS直接傳數據給編譯過的VB 前端程式呈現結果,系統架構簡單有效率且互動功能豐富。而Web版的ASP/ASP. NET應用程式要先將SQL Server或COM+/MTS的結果數據轉換成HTML,再用效率也不高的HTTP通信協定返回到前端,最後還要瀏覽器遵從HTML 或DHTML 指示符,當前繪製界面,整體系統的性能當然不如以往的程式架構。
若用戶端的機器本身很快,使用者或許還感受不到這個差異,然而筆者曾碰到的情況:使用古老的機器,但要求Web Form 長得和Win Form 一樣,並且功能還要更多,而能忍受的回響時間相同,這就難如登天了。

支出

另外,性能調校代表著成本(cost)的支出,成本可能是實質的錢,也可能是工程師的時間與精力,用戶的忍耐等待。在理想狀況下,是把系統中最貴的部分發揮到極限,能夠以最低的成本來發揮系統最大的性能。若是自己開發的程式,這往往代表著硬體採購是系統開發中最貴的部分,因此,會採取重新設計系統的解決方式,如資料庫邏輯使用方式重新切割、查詢方式大量重載、以消耗記憶體的方式減少對硬碟的訪問等。你可能要花掉數個工程師個把月的時間,才得以將架構重新規劃,程式全面重載,或許花費如此的人力成本還不如直接更新設備,但性能調校的總體成本(total cost)並不容易計算。
筆者遇到的大部分狀況是管理者會挑眼前最節約成本的事情先做。一般來說,就是要工程師著手調架構,可能是資料庫的設計,也可能是程式代碼重載,忙了個把月後聲明失敗,最後還是花錢買機器。這種僅看當前最低成本的做法有幾個弊端:
用戶苦等一兩個月,最後還是換機器,他們會覺得工程師能力不足。實際上浪費了人力成本。一陣子後,性能問題又再度浮現。
在動手調校前應該對整個系統的各個瓶頸點瞭然於胸,各花多少成本可以解決,而該瓶頸調整後,整體系統性能可以提升多少。以筆者曾調校的系統為例,整體設計是用IE呈現IIS執行ASP的結果,ASP 調用COM+,COM+訪問SQL Server。系統剛上線時,總回響時間是7秒鐘,但用戶可以接受的時間是3 秒鐘。程式中,個別的時間消耗是IE花費2秒鐘(因為前端PC老舊,而執行操作很複雜),ASP 處理時間0.5 秒鐘,COM+處理時間4秒鐘,SQL Server處理時間0.5秒鐘。
前端PC 數量太大,要升級成本太高。因此,大家都覺得先調後端吧,這時就算工程師花了九牛二虎之力,將三種伺服器的性能都提升一倍,也就是讓原來各伺服器處理時間的總和5秒鐘降為2.5秒鐘,但系統整體時間還是要4.5秒鐘。
用戶罵了一個月之後,在不準更改功能的窘境下,還是要更新前端PC,這時大家就難堪了。所以,事前的整體評估很重要,告知用戶能期待什麼?最後底線是什麼?才有可能讓大家都接受調校的結果。
性能的基線應該都是可以量化的,例如,回響時間、單位時間可執行的批處理數量、單位時間可以處理的數據量、同時上線人數等,都可以求出最大值、最小值、平均值、總數等。針對要調校的目標,先獲取數據後,才可以評估調校的方向是否正確。另外,對系統各環節的性能極限應儘可能地評估一下,不要耗了極大的功夫,才發現其實早已經把某一部分發揮到極限了,再怎么做都不可能提升多少性能,這時你可能需要變更用戶需求、系統架構或必須更換軟硬體。
有些值是當前可以算出來的,例如,直接將用戶訪問數據的T-SQL語句當前執行一遍,可以看出執行該語句的時間,在SQL Server本機上通過管理工具執行一次,在遠程網路上再執行一次,可以約略知道網路是否有影響等。但某些數據可能要特別建立一些環境來測試,例如,沒有用戶,空機的時候某個工作的執行效率如何?有多人上線時,又是如何反應?原本某個工作每秒鐘可以完成多少次,加上什麼運行程式後,每秒鐘只剩幾次等。
另外,如壓力測試時,要仿真多大的數據量,多少人同時上線等,建立這些基線的數據就較為困難,因為仿真的環境要儘量與真實相同。因為不同的數據模型,SQL Server 會建立不同的執行計畫,若是以隨機數產生的數據,往往與真正的數據類型不符,使索引判斷、選擇如何做Join等都會大不相同。
這些基線的數據應該越詳盡越好,不要泛泛地取些值就拿來比較。筆者碰過一位工程師拿著代表某大型系統執行性能的4張圖,上面標著中央處理器主存儲器、硬碟與網路,各有著一條彎彎曲曲描述性能的線,除了記憶體的線長時間在天上之外,其餘的都不高,他就有了結論:記憶體要加大。當然,你讓不懂信息技術的路人甲看這4張圖,跟他解釋圖形的意義,問他要如何調性能,他也會說要加記憶體,因為就只有這張圖看起來和其他3張長得不一樣。
如果公司的錢用不完,這樣的調校似乎就足夠了,全部都靠擴大硬體來提升性能。但就前述的現象,可能要問的是,記憶體與硬碟快取盤交換是否頻繁,數據快取區的高速快取擊中率(cache hit ratio)是否低於90% ,以進一步確認是否為記憶體不足才拖慢整體性能。說不定是資料庫鎖定,也說不定是程式有Bug造成記憶體遺失(memory leak),或是程式本身的Bug造成性能不足等。
若真的是記憶體不足,是否還可以調校?說不定是資料庫系統的設定一開始要占用極大的快取區,所以,大部分的記憶體都被它拿走,但整體來說並沒有有效使用記憶體 。因此,哪個程式吃掉了大部分的資源?誰是主要調校的目標?什麼樣的方向或指針代表調校有效?諸此種種都應該落到文字上,如此可以整理較為清晰的思路,並有可討論的交集,否則一堆沒有共識的專家,恐怕只會眾說紛紜,皆能證明不是自己的錯,但禍首是誰卻說不出來,最後落到會而不議,議而不決的窘況。

相關詞條

熱門詞條

聯絡我們