『壹』 性能測試的內容
性能測試 在軟體的質量保證中起著重要的作用，它包括的測試內容豐富多樣。中國軟體評測中心將性能測試概括為三個方面：應用在客戶端性能的測試、應用在網路上性能的測試和應用在伺服器端性能的測試。通常情況下，三方面有效、合理的結合，可以達到對系統性能全面的分析和瓶頸的預測。 應用在客戶端性能測試的目的是考察客戶端應用的性能，測試的入口是客戶端。它主要包括並發性能測試、疲勞強度測試、大數據量測試和速度測試等，其中並發性能測試是重點。
並發性能測試是重點
並發性能測試的過程是一個負載測試和壓力測試的過程，即逐漸增加負載，直到系統的瓶頸或者不能接收的性能點，通過綜合分析交易執行指標和資源監控指標來確定系統並發性能的過程。負載測試（Load Testing）是確定在各種工作負載下系統的性能，目標是測試當負載逐漸增加時，系統組成部分的相應輸出項，例如通過量、響應時間、CPU負載、內存使用等來決定系統的性能。負載測試是一個分析軟體應用程序和支撐架構、模擬真實環境的使用，從而來確定能夠接收的性能過程。壓力測試（Stress Testing）是通過確定一個系統的瓶頸或者不能接收的性能點，來獲得系統能提供的最大服務級別的測試。
並發性能測試的目的主要體現在三個方面：以真實的業務為依據，選擇有代表性的、關鍵的業務操作設計測試案例，以評價系統的當前性能；當擴展應用程序的功能或者新的應用程序將要被部署時，負載測試會幫助確定系統是否還能夠處理期望的用戶負載，以預測系統的未來性能；通過模擬成百上千個用戶，重復執行和運行測試，可以確認性能瓶頸並優化和調整應用，目的在於尋找到瓶頸問題。
當一家企業自己組織力量或委託軟體公司代為開發一套應用系統的時候，尤其是以後在生產環境中實際使用起來，用戶往往會產生疑問，這套系統能不能承受大量的並發用戶同時訪問? 這類問題最常見於採用聯機事務處理(OLTP)方式資料庫應用、Web瀏覽和視頻點播等系統。這種問題的解決要藉助於科學的軟體測試手段和先進的測試工具。
舉例說明：電信計費軟體
眾所周知，每月20日左右是市話交費的高峰期，全市幾千個收費網點同時啟動。收費過程一般分為兩步，首先要根據用戶提出的電話號碼來查詢出其當月產生費用，然後收取現金並將此用戶修改為已交費狀態。一個用戶看起來簡單的兩個步驟，但當成百上千的終端，同時執行這樣的操作時，情況就大不一樣了，如此眾多的交易同時發生，對應用程序本身、操作系統、中心資料庫伺服器、中間件伺服器、網路設備的承受力都是一個嚴峻的考驗。決策者不可能在發生問題後才考慮系統的承受力，預見軟體的並發承受力，這是在軟體測試階段就應該解決的問題。
大多數公司企業需要支持成百上千名用戶，各類應用環境以及由不同供應商提供的元件組裝起來的復雜產品，難以預知的用戶負載和愈來愈復雜的應用程序，使公司擔憂會發生投放性能差、用戶遭受反應慢、系統失靈等問題。其結果就是導致公司收益的損失。
如何模擬實際情況呢? 找若乾颱電腦和同樣數目的操作人員在同一時刻進行操作，然後拿秒錶記錄下反應時間？ 這樣的手工作坊式的測試方法不切實際，且無法捕捉程序內部變化情況，這樣就需要壓力測試工具的輔助。
測試的基本策略是自動負載測試，通過在一台或幾台PC機上模擬成百或上千的虛擬用戶同時執行業務的情景，對應用程序進行測試，同時記錄下每一事務處理的時間、中間件伺服器峰值數據、資料庫狀態等。通過可重復的、真實的測試能夠徹底地度量應用的可擴展性和性能，確定問題所在以及優化系統性能。預先知道了系統的承受力，就為最終用戶規劃整個運行環境的配置提供了有力的依據。
並發性能測試前的准備工作
測試環境：配置測試環境是測試實施的一個重要階段，測試環境的適合與否會嚴重影響測試結果的真實性和正確性。測試環境包括硬體環境和軟體環境，硬體環境指測試必需的伺服器、客戶端、網路連接設備以及列印機/掃描儀等輔助硬體設備所構成的環境；軟體環境指被測軟體運行時的操作系統、資料庫及其他應用軟體構成的環境。
一個充分准備好的測試環境有三個優點：一個穩定、可重復的測試環境，能夠保證測試結果的正確；保證達到測試執行的技術需求；保證得到正確的、可重復的以及易理解的測試結果。
測試工具：並發性能測試是在客戶端執行的黑盒測試，一般不採用手工方式，而是利用工具採用自動化方式進行。成熟的並發性能測試工具有很多，選擇的依據主要是測試需求和性能價格比。著名的並發性能測試工具有QALoad、LoadRunner、Benchmark Factory和Webstress等。這些測試工具都是自動化負載測試工具，通過可重復的、真實的測試，能夠徹底地度量應用的可擴展性和性能，可以在整個開發生命周期、跨越多種平台、自動執行測試任務，可以模擬成百上千的用戶並發執行關鍵業務而完成對應用程序的測試。
測試數據：在初始的測試環境中需要輸入一些適當的測試數據，目的是識別數據狀態並且驗證用於測試的測試案例，在正式的測試開始以前對測試案例進行調試，將正式測試開始時的錯誤降到最低。在測試進行到關鍵過程環節時，非常有必要進行數據狀態的備份。製造初始數據意味著將合適的數據存儲下來，需要的時候恢復它，初始數據提供了一個基線用來評估測試執行的結果。
在測試正式執行時，還需要准備業務測試數據，比如測試並發查詢業務，那麼要求對應的資料庫和表中有相當的數據量以及數據的種類應能覆蓋全部業務。
模擬真實環境測試，有些軟體，特別是面向大眾的商品化軟體，在測試時常常需要考察在真實環境中的表現。如測試殺毒軟體的掃描速度時，硬碟上布置的不同類型文件的比例要盡量接近真實環境，這樣測試出來的數據才有實際意義。
並發性能測試的種類與指標
並發性能測試的種類取決於並發性能測試工具監控的對象，以QALoad自動化負載測試工具為例。軟體針對各種測試目標提供了DB2、DCOM、ODBC、ORACLE、NETLoad、Corba、QARun、SAP、sqlServer、Sybase、Telnet、TUXEDO、UNIFACE、WinSock、WWW、Java Script等不同的監控對象，支持Windows和UNIX測試環境。
最關鍵的仍然是測試過程中對監控對象的靈活應用，例如三層結構的運行模式廣泛使用，對中間件的並發性能測試作為問題被提到議事日程上來，許多系統都採用了國產中間件，選擇Java Script監控對象，手工編寫腳本，可以達到測試目的。
採用自動化負載測試工具執行的並發性能測試，基本遵循的測試過程有：測試需求與測試內容，測試案例制定，測試環境准備，測試腳本錄制、編寫與調試，腳本分配、回放配置與載入策略，測試執行跟蹤，結果分析與定位問題所在，測試報告與測試評估。
並發性能測試監控的對象不同，測試的主要指標也不相同，主要的測試指標包括交易處理性能指標和UNIX資源監控。其中，交易處理性能指標包括交易結果、每分鍾交易數、交易響應時間（Min：最小伺服器響應時間；Mean：平均伺服器響應時間；Max：最大伺服器響應時間；StdDev：事務處理伺服器響應的偏差，值越大，偏差越大；Median：中值響應時間；90%：90%事務處理的伺服器響應時間）、虛擬並發用戶數。
應用實例：「新華社多媒體資料庫 V1.0」性能測試
中國軟體評測中心（CSTC）根據新華社技術局提出的《多媒體資料庫（一期）性能測試需求》和GB/T 17544《軟體包質量要求和測試》的國家標准，使用工業標准級負載測試工具對新華社使用的「新華社多媒體資料庫 V1.0」進行了性能測試。
性能測試的目的是模擬多用戶並發訪問新華社多媒體資料庫，執行關鍵檢索業務，分析系統性能。
性能測試的重點是針對系統並發壓力負載較大的主要檢索業務，進行並發測試和疲勞測試，系統採用B/S運行模式。並發測試設計了特定時間段內分別在中文庫、英文庫、圖片庫中進行單檢索詞、多檢索詞以及變檢索式、混合檢索業務等並發測試案例。疲勞測試案例為在中文庫中並發用戶數200，進行測試周期約8小時的單檢索詞檢索。在進行並發和疲勞測試的同時，監測的測試指標包括交易處理性能以及UNIX（Linux）、Oracle、Apache資源等。
測試結論：在新華社機房測試環境和內網測試環境中，100M帶寬情況下，針對規定的各並發測試案例，系統能夠承受並發用戶數為200的負載壓力，最大交易數/分鍾達到78.73，運行基本穩定，但隨著負載壓力增大，系統性能有所衰減。
系統能夠承受200並發用戶數持續周期約8小時的疲勞壓力，基本能夠穩定運行。
通過對系統UNIX（Linux）、Oracle和Apache資源的監控，系統資源能夠滿足上述並發和疲勞性能需求，且系統硬體資源尚有較大利用餘地。
當並發用戶數超過200時，監控到HTTP 500、connect和超時錯誤，且Web伺服器報內存溢出錯誤，系統應進一步提高性能，以支持更大並發用戶數。
建議進一步優化軟體系統，充分利用硬體資源，縮短交易響應時間。
疲勞強度與大數據量測試
疲勞測試是採用系統穩定運行情況下能夠支持的最大並發用戶數，持續執行一段時間業務，通過綜合分析交易執行指標和資源監控指標來確定系統處理最大工作量強度性能的過程。
疲勞強度測試可以採用工具自動化的方式進行測試，也可以手工編寫程序測試，其中後者占的比例較大。
一般情況下以伺服器能夠正常穩定響應請求的最大並發用戶數進行一定時間的疲勞測試，獲取交易執行指標數據和系統資源監控數據。如出現錯誤導致測試不能成功執行，則及時調整測試指標，例如降低用戶數、縮短測試周期等。還有一種情況的疲勞測試是對當前系統性能的評估，用系統正常業務情況下並發用戶數為基礎，進行一定時間的疲勞測試。
大數據量測試可以分為兩種類型：針對某些系統存儲、傳輸、統計、查詢等業務進行大數據量的獨立數據量測試；與壓力性能測試、負載性能測試、疲勞性能測試相結合的綜合數據量測試方案。大數據量測試的關鍵是測試數據的准備，可以依靠工具准備測試數據。
速度測試主要是針對關鍵有速度要求的業務進行手工測速度，可以在多次測試的基礎上求平均值，可以和工具測得的響應時間等指標做對比分析。 應用在網路上性能的測試重點是利用成熟先進的自動化技術進行網路應用性能監控、網路應用性能分析和網路預測。
網路應用性能分析
網路應用性能分析的目的是准確展示網路帶寬、延遲、負載和TCP埠的變化是如何影響用戶的響應時間的。利用網路應用性能分析工具，例如Application Expert，能夠發現應用的瓶頸，我們可知應用在網路上運行時在每個階段發生的應用行為，在應用線程級分析應用的問題。可以解決多種問題：客戶端是否對資料庫伺服器運行了不必要的請求？當伺服器從客戶端接受了一個查詢，應用伺服器是否花費了不可接受的時間聯系資料庫伺服器？在投產前預測應用的響應時間；利用Application Expert調整應用在廣域網上的性能；Application Expert能夠讓你快速、容易地模擬應用性能，根據最終用戶在不同網路配置環境下的響應時間，用戶可以根據自己的條件決定應用投產的網路環境。
網路應用性能監控
在系統試運行之後，需要及時准確地了解網路上正在發生什麼事情；什麼應用在運行，如何運行；多少PC正在訪問LAN或WAN；哪些應用程序導致系統瓶頸或資源競爭，這時網路應用性能監控以及網路資源管理對系統的正常穩定運行是非常關鍵的。利用網路應用性能監控工具，可以達到事半功倍的效果，在這方面我們可以提供的工具是Network Vantage。通俗地講，它主要用來分析關鍵應用程序的性能，定位問題的根源是在客戶端、伺服器、應用程序還是網路。在大多數情況下用戶較關心的問題還有哪些應用程序佔用大量帶寬，哪些用戶產生了最大的網路流量，這個工具同樣能滿足要求。
網路預測
考慮到系統未來發展的擴展性，預測網路流量的變化、網路結構的變化對用戶系統的影響非常重要。根據規劃數據進行預測並及時提供網路性能預測數據。我們利用網路預測分析容量規劃工具PREDICTOR可以作到：設置服務水平、完成日網路容量規劃、離線測試網路、網路失效和容量極限分析、完成日常故障診斷、預測網路設備遷移和網路設備升級對整個網路的影響。
從網路管理軟體獲取網路拓撲結構、從現有的流量監控軟體獲取流量信息（若沒有這類軟體可人工生成流量數據），這樣可以得到現有網路的基本結構。在基本結構的基礎上，可根據網路結構的變化、網路流量的變化生成報告和圖表，說明這些變化是如何影響網路性能的。PREDICTOR提供如下信息：根據預測的結果幫助用戶及時升級網路，避免因關鍵設備超過利用閥值導致系統性能下降；哪個網路設備需要升級，這樣可減少網路延遲、避免網路瓶頸；根據預測的結果避免不必要的網路升級。 對於應用在伺服器上性能的測試，可以採用工具監控，也可以使用系統本身的監控命令，例如Tuxedo中可以使用Top命令監控資源使用情況。實施測試的目的是實現伺服器設備、伺服器操作系統、資料庫系統、應用在伺服器上性能的全面監控，測試原理如下圖。
UNIX資源監控指標和描述
監控指標 描述
平均負載 系統正常狀態下，最後60秒同步進程的平均個數
沖突率 在乙太網上監測到的每秒沖突數
進程/線程交換率 進程和線程之間每秒交換次數
CPU利用率 CPU佔用率（%）
磁碟交換率 磁碟交換速率
接收包錯誤率 接收乙太網數據包時每秒錯誤數
包輸入率 每秒輸入的乙太網數據包數目
中斷速率 CPU每秒處理的中斷數
輸出包錯誤率 發送乙太網數據包時每秒錯誤數
包輸入率 每秒輸出的乙太網數據包數目
讀入內存頁速率 物理內存中每秒讀入內存頁的數目
寫出內存頁速率 每秒從物理內存中寫到頁文件中的內存頁數
目或者從物理內存中刪掉的內存頁數目
內存頁交換速率 每秒寫入內存頁和從物理內存中讀出頁的個數
進程入交換率 交換區輸入的進程數目
進程出交換率 交換區輸出的進程數目
系統CPU利用率 系統的CPU佔用率（%）
用戶CPU利用率 用戶模式下的CPU佔用率（%）
磁碟阻塞 磁碟每秒阻塞的位元組數
『貳』 sql並發壓力測試用什麼小工具SQL Stress怎麼用
SQLSERVER帶的命令行實用工具用來運行特殊的T-SQL語句和腳本。這個工具不是很常用。語法：首先CMD進入控制台，然後輸入SQLCMD進入默認的實例。-S實例名連接命名實例-i腳本文件運行-o文件名將輸出結果保存到指定文件
『叄』 sqlserver資料庫壓力測試用什麼工具比較好，是直接對資料庫進行壓力測試的
loadrunner，負載測試用的很多。
『肆』 如何利用loadrunner做mysql壓力測試
LoadRunner測試資料庫是模擬客戶端去連接資料庫伺服器，因此，需要協議（或者說驅動的支持）。LoadRunner本身直接支持Oracle、SqlServer資料庫，這兩個資料庫直接選擇相應的協議就可以錄制腳本。而MySQL資料庫只能利用ODBC協議來錄制（編寫）腳本，所以必須要MySql的ODBC驅動，和支持ODBC的查詢分析器（錄腳本需要，自己編寫就不需要）。
『伍』 怎樣查出SQLServer的性能瓶頸
SQLServer性能監控
這套性能優化的清單將至少准科學的幫助你找出你的SQLServer任何明顯的性能問題。說是這樣說，SQLServer的性能調優仍然是很困難的。我試圖用這套清單去找出「容易」的sqlserver性能問題，困難的留待稍後。我這樣做是因為很容易將容易和困難的的性能調優問題搞混。通過列出一個「容易」的性能調優范圍，就很容易的將這些問題解決，一旦解決了這些容易的問題，那麼你就能集中去解決更困難的問題。
使用這個SQLServer性能調優清單的一個好處是，它將不僅僅告訴你目前最容易解決的性能問題是什麼，而且還幫助你正確的去解決。在某種程度上，你可以選擇不同的順序進行。換句話說，你可以故意做出特殊的決定而不是按照清單通常的順序進行。某種意義上說你是對的，不是所有的性能調優建議都適合所有的情形。另外，你的決定是基於你的資源限制，例如沒有足夠的錢去買滿足負荷的硬體。如果真是那樣的話，你就別無選擇了。還有，你的決定可能基於一些政治原因，那是你不得不作出的改變。不管怎樣，你需要知道你能做什麼，使用這個性能調優清單找出你能改變的范圍並做出相應的改變提升你的SQLServer的性能。
一般來說，你將在你的每一個SQL伺服器上執行這個清單。如果遇到清單中的一些問題，這會花掉你一些時間。我建議你從目前性能問題最多的的伺服器開始，然後當你有時間的時候按照自己的思路去解決其他伺服器。
一旦你完成了，可仍然有很多事情要去做。記住，這些只是一些容易的。一旦你完成了這些容易的，接下來你需要花時間去解決更困難問題。這個是另一篇文章要解決的問題了。
怎樣進行你的SQLServer性能調優呢?
為了使其變得容易，我把它們分成了以下幾個部分：
？ 使用性能監視器找出硬體瓶頸
？ SQLServer硬體性能監控列表
？ 操作系統性能監控列表
？ SQLServer2000配置性能監控列表
？ 資料庫配置設置性能監控列表
？ 索引性能監控列表
？ 應用程序和T-SQL性能監控列表
？ SQLServer資料庫作業性能監控列表
？ 使用Profiler找出低效的查詢
？ 怎樣最好的實現SQLServer性能監控
管理你的SQLServe性能的最好方法是首先回顧上面每一部分的內容，把它們列印出來。然後完成每一部分的內容，寫下你收集到的結果。你也可以按照你喜歡的順序進行。上面的步驟僅僅列出了我執行的順序，因為那樣通常能達到一個比較好的效果。
性能監控列表
計數器名稱 均值 最小值 最大值
Memory: Pages/sec
Memory: Available Bytes
Physical Disk: % Disk time
Physical Disk: Avg. Disk Queue Length
Processor: % Processor Time
System: Processor Queue Length
SQL Server Buffer: Buffer Cache Hit Ratio
SQL Server General: User Connections
在上表輸入你的結果.
使用性能監視器找出SQLServer硬體瓶頸
開始SQLServer性能調優的最佳地方就是從性能監視器（系統監視器）開始。通過一個24小時的周期對一些關鍵的計數器進行監控，你將對你SQLServer伺服器的硬體瓶頸了如指掌。
一般來說，使用性能監視器去創建一個一些關鍵的計數器的24小時周期的監控日誌。當你決定創建這個日誌的時候，你需要選擇一個典型的24小時的周期，例如，選擇一個典型的比較忙的日期，而不是周日或節假日。
一旦你將這些捕獲的數據形成日誌後，在性能監視器的圖形界面下會顯示計數器的推薦值。你在上表中記下均值、最小值、峰值。做完這些後，用你的結果跟下面的分析比較。通過你的結果和下面的建議值進行比較，你將能快速的找到你的SQLServe正在經歷的潛在的硬體瓶頸。
關鍵性能計數器說明
下面是不同關鍵性能計數器的一個討論，它們的建議值和為了幫助解決硬體瓶頸問題的一些選項。注意我已經限制了性能監視器需要監視的一些關鍵計數器。我這么做是因為在本文我們的目的是為了容易的找到顯而易見的性能問題，許多其他的性能監視器計數器你能在本網站其他地方找到。
Memory: Pages/sec
這個計數器記錄的是每秒鍾內存和磁碟之間交換的頁面數。交換更多的頁面、超過你伺服器承受的更多的I/O，將輪流降低你SQLserver的性能。你的目的就是盡量將頁面減少到最小，而不是消除它。
如果你的伺服器上SQLServer是最主要的應用程序，那麼這個值的理想范圍是0～20之間。可能很多時候你看到的值都會超過20。這個值一般要保持在每秒的平均頁數在20以下。
如果這個值平均總是超過20，其中最大的一個可能是內存瓶頸問題，需要增加內存。通常來說，更多的內存意味著需要執行的頁面更少。
在大多數情況下，伺服器決定SQLServer使用的適當內存的大小，頁面將平均小於20。給SQLServer適當的內存意味著伺服器的緩存命中率（Buffer Hit Cache Ratio 這個稍後會講到）達到99％或者更高。如果在一個24小時的周期里你的sqlserver的緩存命中率達到99％或者更高，但是在這個期間你的頁面數總是超過20，這意味著你或許運行了其他的程序。如果是這樣的情況，建議你移除這些程序，使SQLServer是你的伺服器的最主要的程序。
如果你的sqlserver伺服器沒有運行其他程序，並且在一個24小時的周期里頁面數總是超過20，這說明你應該修改你對SQLServer的內存設置了。將其設置為「動態配置SQLServer的內存」，並且最大內存設置得高一些。為了達到最優，SQLServer將盡可能的獲得多的內存以完成自己的工作，而不是去和其他的程序爭奪內存。
Memory: Available Bytes
另一個檢查SQLServer是否有足夠的物理內存的方法是檢查Memory Object: Available Bytes計數器。 這個值至少大於5M，否則需要添加更多的物理內存。在一個專門的SQLServer伺服器上，SQLServer試圖維持4-10M的自由物理內存，其餘的物理內存被操作系統和SQLServer使用。當可用的物理內存接近5M或者更低時，SQLServer最可能因為缺少內存而遇到性能瓶頸。遇此情況，你需要增加物理內存以減少伺服器的負荷，或者給SQLServer配置一個合適的內存。
Physical Disk: % Disk Time
這個計數器度量磁碟陣列繁忙程度（不是邏輯分區或磁碟陣列上獨立的磁碟）。它提供一個對磁碟陣列繁忙程度相對較好的度量。原則上計數器% Disk Time的值應該小於55%。如果持續超過55%（在你24小時的監控周期里大約超過10分鍾），說明你的SQLServer有I/O瓶頸。如果你只是偶爾看到，也不必太擔心。但是，如果經常發生的話（也就是說，一個小時出現好幾次），就應該著手尋找增加伺服器I/O性能或者減少伺服器負荷的解決之道了。一般是為磁碟陣列增加磁碟，或者更好更快的磁碟，或者給控制器卡增加緩存，或者使用不同版本的RAID，或者更換更快的控制器。
在NT4.0上使用該計數器之前，確認在NT命令提示符下輸入diskperf -y，重啟伺服器，以便手動打開。在NT4.0下第一次必須將該計數器打開，Windows2000默認是打開的。
Physical Disk: Avg. Disk Queue Length
除了觀察物理磁碟的% Disk Time計數器外，還可以用Avg. Disk Queue Length計數器。磁碟陣列中的各個磁碟的該值如果超過2（在你24小時的監控周期里大約超過10分鍾），那麼你的磁碟陣列存在I/O瓶頸問題。象計數器% Disk Time一樣，如果只是偶爾看到，也不必太擔心。但是，如果經常發生的話，就應該著手尋找增加伺服器I/O性能的解決之道了。如前所述。
你需要計算這個值，因為性能監視器不知道你的磁碟陣列中有多少物理磁碟。例如，如果你有一個6個物理磁碟組成的磁碟陣列，它的Avg.
Disk Queue Length值為10，那麼實際每個磁碟的值為1.66（10/6＝1.66），它們都在建議值2以內。
在NT4.0上使用該計數器之前，確認在NT命令提示符下輸入diskperf -y，重啟伺服器，以便手動打開。在NT4.0下第一次必須將該計數器打開，Windows2000默認是打開的。
一起使用這兩個計數器將幫助你找出I/O瓶頸。例如，如果% Disk Time的值超過55%，Avg. Disk Queue Length計數器值超過2，伺服器則存在I/O瓶頸。
Processor: % Processor Time
處理器對象： % Processor Time計數器對每一個CPU可用，並針對每一個CPU進行檢測。同樣對於所有的CPU也可用。這是一個觀察CPU利用率的關鍵計數器。如果% Total Processor Time計數器的值持續超過80%（在你24小時的監控周期里大約超過10分鍾），說明CPU存在瓶頸問題。如果只是偶爾發生，並且你認為對你的伺服器影響不大，那沒問題。如果經常發生，你應該減少伺服器的負載，更換更高頻率的CPU，或者增加CPU的數量或者增加CPU的2級緩存（L2 cache）。
System: Processor Queue Length
根據% Processor Time計數器，你可以監控Processor Queue Length計數器。每個CPU的該值如果持續超過2（在你24小時的監控周期里大約超過10分鍾），那麼你的CPU存在瓶頸問題。例如，如果你的伺服器有4個CPU，Processor Queue Length計數器的值總共不應超過8。
如果Processor Queue Length計數器的值有規律的超過建議的最大值，但是CPU利用率相對不是很高，那麼考慮減少SQLServer的"max worker threads"的配置值。Processor Queue Length計數器的值高的可能原因是有太多的工作線程等待處理。通過減少"maximum worker threads"的值，強迫線程池踢掉某些線程，從而使線程池得到最大的利用。
一起使用計數器Processor Queue Length和計數器% Total Process Time，你可以找到CPU瓶頸，如果都顯示超過它們的建議值，可以確信存在CPU瓶頸問題。
SQL Server Buffer: Buffer Cache Hit Ratio
SQL Server Buffer中的計數器Buffer Cache Hit Ratio用來指出SQLServer從緩存中而不是磁碟中獲得數據的頻率。在一個OLTP程序中，該比率應該超過90%，理想值是超過99%。如果你的buffer cache hit ratio低於90%，你需要立即增加內存。如果該比率在90%和99%之間，你應該認真考慮購買更多的內存了。如果接近99%，你的SQLServer性能是比較快的了。某些情況下，如果你的資料庫非常大，你不可能達到99%，即使你在伺服器上配置了最大的內存。你所能做的就是盡可能的添加內存。
在OLAP程序中，由於其本身的工作原理，該比率大大減少。不管怎樣，更多的內存總是能提高SQLServer的性能。
SQL Server General: User Connections
既然sqlserver的使用人數會影響它的性能，你就需要專注於sqlserver的General Statistics Object: User Connections計數器。它顯示sqlserver目前連接的數量，而不是用戶數。
如果該計數器超過255，那麼你需要將sqlserver的"Maximum Worker Threads" 的配置值設置得比預設值255高。如果連接的數量超過可用的線程數，那麼sqlserver將共享線程，這樣會影響性能。"Maximum Worker Threads"需要設置得比你伺服器曾經達到的最大連接數更高。
『陸』 壓力測試，用的伺服器是windows 2008server，資料庫sqlserver，請問這兩個上面最好的監控工具是什麼
loadrunner
『柒』 如何測試sqlserver資料庫壓力
壓力測試的范疇非常大的,包括磁碟io 網路吞吐 應用程序測試等
一般專業的做法是請測試工程師幫忙測試
磁碟io測試工具你可以考慮SQLIO SQLIOSIM 微軟自己的東西你可以放心
網路吞吐測試工具就比較廣泛了 比如樓上也有人提到TTCPW,還有你可以參考一些黑盒壓力測試軟體比如qacenter等！
『捌』 sysbench 可以壓測sqlserver嗎
1、CPU運算性能
2、磁碟IO性能
3、調度程序性能
4、內存分配及傳輸速度
5、POSIX線程性能
6、資料庫性能(OLTP基準測試)