爲何個人數據庫應用程序這麼慢？

爲何個人數據庫應用程序這麼慢？

當您的應用程序運行緩慢時，反射操做是指責數據庫查詢。
毫無疑問，一些更爲奢侈的拖延可能會由於缺失的指數或沒必要要的鎖定而被指責，但還有其餘潛在惡做劇，包括網絡和應用自己。 Dan
Turner指出，你能夠節省大量的時間和金錢，經過努力肯定問題所在的位置，而後潛入細節。

低應用程序首先影響終端用戶，可是整個團隊很快就會感覺到影響，包括DBA，Dev團隊，網絡管理員以及照管硬件的系統管理員。

有這麼多人蔘與，每一個人都有本身的見解，可能的緣由，可能很難肯定瓶頸在哪裏。

通常來講，SQL Server應用程序的性能問題有兩個主要緣由：

• 網絡問題 - 與將SQL應用程序客戶端鏈接到數據庫的「管道」的速度和容量有關
• 處理時間慢 - 在管道的末端，涉及要求處理的速度和效率。

在本文中，咱們將詳細介紹如何診斷這些問題，並瞭解最底層的性能問題。

網絡問題

網絡性能問題普遍地分解爲與網絡響應速度（延遲）或網絡容量（帶寬）相關的問題，即在必定時間內可傳輸多少數據。

固然這二者是相互聯繫的。 若是您的應用程序（或同一網絡上的其餘應用程序）生成的網絡流量壓倒可用帶寬，則這可能會增長延遲。

延遲

延遲是在應用程序和SQL Server之間發送TCP數據包所需的時間。 在DB上和降低的路上，您會產生延遲。 人們一般會談論往返時間的延遲：即到達那裏的時間

圖1顯示了60毫秒的往返行程。
圖1

帶寬

能夠以必定的時間量發送或接收的數據量，一般以kb / s或Mb / s（兆比特每秒）爲單位。

在討論帶寬時，人們常常談論「管道的大小」，這是一個很好的類比（再加上它聽起來很頑皮）：你的管道越多，你能夠一次得到更多的數據。

若是您的應用程序須要接收10兆字節的響應（這是80兆比特！），而且您有20 Mb / s的鏈接，則響應將至少須要4秒鐘。 若是您有10Mb / s鏈接，則至少須要8秒鐘的時間。 若是您的網絡上的其餘人正在流式傳播「權力」遊戲，那麼這將下降可用帶寬以供您使用。

應用問題：處理時間慢

每當客戶端向SQL Server發送請求時，要檢索所需的數據集，完成請求所需的總處理時間都包括：

應用程序處理時間：應用程序在發送下一個請求以前處理上一個響應中的數據須要多長時間
SQL處理時間：SQL在發送響應以前花費多少時間處理請求
圖2提供了這個概念的簡單說明。
圖2

時間都花在哪了？

咱們花費了大量時間來調查客戶端/服務器SQL應用程序的性能，而且還有絕大多數不一樣的工具，腳本和方法來幫助您排除任何數量的不一樣類型的性能問題。

那麼當面對緩慢的應用程序響應時間的時候，咱們可否快速找出問題的根本緣由？ 圖3中的流程圖顯示了一種系統的方法來解決問題。

圖3

調查性能問題時，可能有多個問題。值得一看的應用程序的幾個不一樣的部分。這是一個廣泛的問題嗎？仍是比別人慢一些？

最好小開始。若是您能夠專一於特別緩慢的應用程序的某個特定區域，那麼可讓生活更輕鬆，例如，當您點擊發票頁面上的「全選」按鈕時，加載結果須要10秒鐘。專一於一個小型可重複的工做流將讓您隔離問題。

接下來的問題固然是爲何要花10秒鐘？縮小問題的第一個也是最簡單的方法是將應用程序儘量靠近SQL Server，在同一臺機器上或在同一個LAN上運行。

若是有效地消除了任何網絡延遲和帶寬限制，則忽然須要一秒鐘或更短期才能選擇全部發票，那麼您須要調查哪些網絡問題可能在其他時間內消失。

若是應用程序仍然須要10秒鐘的時間來加載結果，那麼恭喜，您再次消除了4個問題中的2個！如今，您須要查看處理時間大部分在哪裏。

咱們來仔細看一下如何解決這段時間大部分消費的地方。您將須要Wireshark或SQL Profiler（不管您更加溫馨）。

調查申請處理時間

您將在兩個地方之間看到時間：發送應用程序的響應和獲取下一個請求（應用程序處理時間）之間或在發出SQL Server請求和獲取響應（SQL處理時間）之間的時間。

要解決哪個致使您的問題，您可使用Wireshark或SQL Profiler，由於二者均可以告訴咱們大體的應用程序和SQL處理時間（儘管確切的數字可能會略有不一樣）。

使用Wireshark

咱們可使用Wireshark在工做流執行時捕獲網絡流量。使用Wireshark，咱們能夠過濾非應用程序流量，並查看工做流中全部數據包之間的時差。

計算近似應用處理時間：

1. 捕獲工做流的數據包：啓動Wireshark捕獲並運行應用程序工做流程，請記住在工做流完成後中止捕獲。請記住選擇相關的網絡界面，並注意您須要在與Wireshark的數據庫不一樣的計算機上運行應用程序以查看流量​​。確保您沒有運行任何其餘本地SQL應用程序，而不是您嘗試捕獲的其餘本地SQL應用程序。
2. 經過應用過濾器tds，而後應用文件|來擺脫非應用程序流量導出指定的數據包，提供一個文件名，並確保選中「顯示」。在Wireshark中打開這個新文件。
3. 顯示當前和上一個數據包之間的時差，只需添加時間增量列，以下所示：
4. 選擇編輯|偏好|外觀|列
5. 點擊+按鈕，將類型下拉菜單更改成「達美時間」，將標題更改成「Delta」
6. 過濾流量只須要：
   （tds.type == 0x01 || tds.type == 0x03 || tds.type == 0x0E）&& tds.packet_number == 1

上述過濾器將僅顯示每一個請求中的第一個TDS數據包，「增量」列如今將顯示先前請求的最後一個響應數據包與下次請求之間的時間。確保數據包由「否」列排序，由於這將確保數據包按照發送/接收的順序。

1. 導出爲CSV，經過導航文件|導出數據包解析|做爲CSV
2. 計算應用程序處理時間（以秒爲單位） - 在Excel中打開CSV，並總結「增量」列中的值。

要獲取大體的SQL處理時間：

1. 從新打開您在Wireshark中的步驟2中建立的文件，將流量過濾到只有響應：
   tds.type == 0x04 && tds.packet_number == 1

上述過濾器將僅顯示每一個響應中的第一個TDS數據包，「增量」列如今將顯示先前請求的最後一個請求數據包與從SQL Server發回的第一個響應數據包之間的時間。一樣，請確保數據包由「否」列排序。

1. 導出爲CSV，經過導航文件|導出數據包解析|做爲CSV
2. 計算SQL處理時間（以秒爲單位） - 在Excel中打開CSV並總結「列」列中的值。

使用SQL Profiler

雖然已知使用SQL Profiler收集診斷數據會爲您的工做流程增長一些開銷，但它仍然能夠給您一個普遍的處理時間。 您能夠經過運行服務器端跟蹤，而後以下所述導出數據來最小化此開銷。 或者，若是您對擴展事件和XQuery有信心，您應該能夠經過該路徑獲取相似的數據。

首先經過捕獲工做流的Profiler跟蹤，只需使用「標準（默認）」跟蹤模板。 確保沒有其餘的東西在同一時間觸發數據庫，因此你只捕獲你的流量。 捕獲跟蹤中的工做負載後，使用File |將其保存到跟蹤表 另存爲| 跟蹤表。

在SQL Management Studio中，使用如下兩個查詢查詢您建立的表，以便爲您提供大體的應用程序和SQL處理時間：

/* Calculate approximate SQL Processing time for RPCs and SQL Batch queries*/
  SELECT SUM(DATEDIFF(MILLISECOND, StartTime, EndTime)) AS 'SQL Processing Time in ms'
  FROM TraceTable
  WHERE EventClass IN ( 10, 12 );
  -- Selects the sum of the time difference between the start and end times 
  -- for event classes 10 (RPC:Completed) and 12 (SQL:BatchCompleted)
  /* Calculate approximate app processing time*/
  WITH Events
  AS (SELECT *
      FROM TraceTable
      WHERE EventClass IN ( 10, 11, 12, 13 )
     )
  SELECT SUM(DATEDIFF(MILLISECOND, PreviousRow.EndTime, CurrentRow.StartTime)) AS 'App Processing Time in ms'
  FROM Events CurrentRow
      JOIN Events PreviousRow
          ON CurrentRow.RowNumber = PreviousRow.RowNumber + 1
  WHERE CurrentRow.eventclass IN ( 11, 13 )
        AND PreviousRow.eventclass IN ( 10, 12 );
  -- Select the sum of the time difference between an end of query event 
  -- (either 10 RPC:Completed or 12 SQL:BatchCompleted)
  -- and the next query starting event
  -- (either 11 RPC:Starting or 13 SQL:BatchStarting)

調查延遲和帶寬問題

若是應用程序在本地運行時很快，看起來您有網絡問題。 此時，您將須要知道應用程序和SQL Server之間的延遲。 你能夠從一個ping上獲得一個粗略的想法，這將告訴你二者之間的往返時間。 當網絡處於低負載狀態時，嘗試並進行測量，由於網絡負載高可能會增長ping次數。

若是您計算應用程序發出的查詢數量，您能夠計算延遲所花費的時間。

要獲取Wireshark的查詢數量，您能夠應用如下過濾器，而後查看狀態欄中的「顯示」計數：

(tds.type == 0x01 || tds.type==0x03 || tds.type == 0x0E) && tds.packet_number == 1

要獲取SQL Profiler中的查詢數量，請按前述建立一個跟蹤表，並運行如下查詢：

SELECT COUNT(1) FROM TraceTable WHERE EventClass in (11,13)

您須要將此查詢計數乘以網絡延遲（ping值）。例如，若是應用程序發送100個查詢，而且您的網絡延遲爲60ms，則總通行時間爲100 60 = 6000ms（6秒），而在LAN上，則須要100 1 = 100ms（0.1秒）。

這應該告訴你延遲是不是你的問題。若是不是，那麼你有一個帶寬問題。

過了一下子咱們沒有明確看到帶寬問題，咱們只是排除了其餘問題。咱們如何確認？很好的問題恐怕會有點兒吃驚

若是您有一個具備流量監控的網絡級設備，以及與SQL Server的專用鏈接，則能夠查看您的工做流程是否使可用帶寬飽和。

或者，當您知道您沒有帶寬瓶頸時，您須要查看應用程序使用多少帶寬。爲此，您還須要運行靠近數據庫的應用程序，捕獲Wireshark中的數據包，並檢查應用程序使用的帶寬。一樣，請確保您沒有運行任何其餘本地SQL應用程序，而不是您嘗試捕獲的其餘本地SQL應用程序。

一旦你完成了Wireshark的捕獲：

1. 使用過濾器：tds
2. 點擊統計|對話並勾選「限制顯示過濾器」框。而後，您應該在會話窗口中看到您的App工做流對話。
3. 使用的帶寬顯示爲「字節A - > B」和「字節B - > A」
   在高延遲網絡上運行應用程序時重複捕獲，並再次查看使用的帶寬。若是二者之間存在較大的差別，那麼您可能帶寬受限。

固然，爲了準確比較，您須要在兩個測試中運行SQL Server和相似硬件上的應用程序。例如，若是SQL Server在功能不強的硬件上運行，那麼在給定的時間內，它將在整個網絡中產生更少的流量。

根本緣由分析

頗有可能你有多個問題！可是，在完成上述步驟以後，您應該可以將全部時間用於處理工做流程。若是10秒的處理時間顯示爲6秒的SQL處理時間，3秒的傳輸時間和1秒的應用處理時間，那麼您將瞭解如何肯定您的調查的優先級。

若是主要問題是緩慢的SQL處理時間，那麼有不少關於調優和跟蹤問題的信息。例如，因爲咱們已經捕獲了Profiler跟蹤，Gail Shaw的文章很好地概述瞭如何在跟蹤中查找對性能問題最有貢獻的過程和批處理。此外，Jonathan Kehayias的書很是適合對SQL Server中常見的性能問題進行故障排除。

相反，若是大部分時間花在客戶端處理中，您可能須要考慮對應用程序代碼進行分析以查找問題。根據您的編程語言（例如，對於.NET語言，您可使用來自Redgate的ANTS或JetBrains的dotTrace），有不少分析工具。

若是您遇到網絡帶寬問題，則可能須要限制您要求的數據的大小。例如，在請求數據時不要使用「SELECT *」。只返回必要的列，並使用WHERE或HAVING過濾器僅返回必要的行。

在咱們的經驗中，性能問題的一個常見緣由是經過高延遲網絡運行「聊天」應用程序。一個聊天應用程序是發送許多重複和沒必要要的查詢，使得更多的網絡往返行程比必要。

一般，這些應用程序最初是在高速LAN上開發並部署的，因此「chattiness」歷來沒有真正引發問題。當數據移動到不一樣的位置（如雲端）時，會發生什麼？或者不一樣大陸的客戶試圖訪問？或者您須要構建地理上多樣化的災難恢復環境？若是您考慮在一個1ms的LAN上的每一個查詢在60ms廣域網上的速度將會下降60倍，那麼您能夠看到這樣會如何影響您的性能。

簡而言之，在編寫客戶端/服務器應用程序時，您須要避免頻繁執行相同的查詢，以最大限度地減小必要的往返次數來收集所需的數據。這兩種最多見的方法是：

• 重寫代碼 - 例如，您能夠聚合和過濾服務器上的多個數據集，以免每一個數據集進行查詢，儘管並不老是更改應用程序
• 使用查詢預取和緩存 - 有一些WAN優化工具能夠作到這一點，但它們有時是昂貴的，難以配置以得到高性能，而不會在應用程序中引入錯誤

咱們對這些問題進行了大量的研究，同時開發了數據加速器工具，並採用了一種使用機器學習來預測應用程序要作什麼的方法，並預取所需的數據，所以它準備就緒由於應用程序請求它。

總結

在您花費大量時間和金錢的可能解決方案以前，確保您解決問題所在。 咱們已經看到，當公司最大的問題出如今應用程序性能問題上時，公司花費大量資金和人力時間來優化SQL查詢。 相反，咱們已經看到，企業將愈來愈多的內存或CPU放入SQL服務器，這樣作永遠不會彌補網絡延遲的額外時間。 若是您能夠肯定工做流程處理時間的真正用途，您能夠以正確的方式指導您的時間和精力。

但願這可讓您瞭解如何調查本身的應用程序的性能，或者開始追蹤您可能遇到的任何問題。