翻譯 為什麽我的數據庫應用程序如此緩慢?
為什麽我的數據庫應用程序如此緩慢?
當您的應用程序運行緩慢時，反射操作將會導致數據庫查詢。誠然，一些更為奢侈的延遲可以被公平地歸咎於缺失的索引或不必要的鎖定，但在這出戲中還有其他潛在的反派角色，包括網絡和應用程序本身。丹·特納(Dan Turner)指出，你可以在深入細節之前確定問題的所在，從而節省大量的時間和金錢。
緩慢的應用程序首先會影響最終用戶，但是整個團隊很快就會感受到影響，包括DBA、Dev團隊、網絡管理員和系統管理員。
有這麽多人參與其中，每個人都有自己的觀點，很難確定瓶頸到底在哪裏。
一般來說，SQL Server應用程序的性能問題主要有兩個原因:
網絡問題——與“管道”連接您的SQL應用程序客戶機到數據庫的“管道”的速度和容量有關
緩慢的處理時間——與處理請求的速度和效率有關，在管道的一端。
在本文中，我們將詳細介紹如何診斷這些問題，並了解性能問題的底層。
網絡問題
網絡性能問題廣泛地分解成與網絡(延遲)或網絡容量(帶寬)的響應速度相關的問題，即它可以在一個設置的時間內傳輸多少數據。
當然，兩者是相互關聯的。如果你的應用程序(或同一網絡上的其他應用程序)產生的網絡流量超過了可用的帶寬，那麽這將會增加延遲。
延遲
延遲是在應用程序和SQL服務器之間發送TCP包所需的時間。你在到達DB的路上會引起延遲，然後在下降的時候。人們通常在往返時間上談論延遲時間:即到達那裏和返回的時間
圖1顯示了一個60毫秒的往返行程。
帶寬
可以在一段時間內發送或接收的數據量，通常以kb / s或Mb / s(兆比特每秒)來計算。
人們在討論帶寬時經常談論“你的管道的大小”，這是一個很好的類比(加上它聽起來很頑皮):你的管道越肥，你能同時通過它的數據越多。
如果你的應用程序需要接收10兆字節的響應(這是80兆位!)，並且你有20 Mb/ s的連接，響應至少需要4秒才能收到。如果你有10Mb / s的連接，至少需要8秒的時間。如果你的網絡上的其他人都在觀看《權力的遊戲》，那將會減少可用的帶寬。
應用程序問題:緩慢的處理時間
每當客戶端向SQL Server發送請求時，要檢索所需的數據集，完成請求所需的總處理時間包括:
應用程序處理時間:在發送下一個請求之前，應用程序需要多長時間來處理之前的響應的數據
SQL處理時間:SQL在發送響應之前花多長時間處理請求
圖2提供了這個概念的簡單說明。
時間花在哪裏?
我們花了很多時間來研究客戶機/服務器SQL應用程序的性能，並且有大量不同的工具、腳本和方法來幫助您解決各種不同類型的性能問題。
那麽，當面對緩慢的應用程序響應時間時，我們如何快速確定問題的根本原因呢?圖3中的流程圖展示了一種處理問題的系統方法。
在調查性能問題時，您可能會遇到不止一個問題。看看應用程序的幾個不同部分，這是一個普遍問題嗎?或者有些部件比其他部件慢得多?
最好從小做起。如果你能專註於一個特別慢的應用程序的特定區域，它會讓生活變得更簡單，例如，當你點擊發票頁面上的“選擇所有”按鈕時，加載結果需要10秒。專註於一個可重復的小工作流可以讓您隔離這個問題。
下一個要回答的問題是，為什麽要花10秒鐘?縮小問題的第一個也是最簡單的方法是，在同一個機器上，或者在同一個局域網中，盡可能地將應用程序運行到SQL Server上。
如果有效地刪除了任何網絡延遲和帶寬限制，它突然需要一秒或更少的時間來選擇所有的發票，然後您需要調查什麽網絡問題可能會在其余的時間裏消耗掉。
如果應用程序仍然花10秒來加載結果，那麽恭喜你，你又一次刪除了4個問題中的2個!現在，您需要查看正在使用的大部分處理時間。
讓我們仔細看看如何計算出這段時間的大部分時間花在哪裏。您將需要Wireshark或SQL Profiler(以您更舒適的方式)。
調查應用程序處理時間
您將在兩個位置中的一個中看到時間:在向應用程序發送響應和獲取下一個請求(應用程序處理時間)之間，或者在向SQL Server發出請求並得到響應(SQL處理時間)之間進行。
為了找出導致您的問題的原因，您可以使用Wireshark或SQL Profiler，因為兩者都可以告訴我們大致的應用程序和SQL處理時間(盡管確切的數字可能略有不同)。
使用Wireshark
我們可以使用Wireshark在工作流執行時捕獲網絡流量。使用Wireshark允許我們過濾非應用程序的流量，並查看工作流中所有數據包之間的時間差異。
計算近似應用程序處理時間:
捕獲工作流的包:啟動Wireshark捕獲並運行應用程序工作流，記住在工作流完成後停止捕獲。記得選擇相關的網絡接口，並註意，你需要在不同的機器上運行這個應用程序，從數據庫到Wireshark，以查看流量。確保您沒有運行其他的本地SQL應用程序，而不是您試圖捕獲的其他SQL應用程序。
通過應用過濾器tds來擺脫非應用程序的流量，然後文件|導出指定的包，給出一個文件名並確保“顯示”。在Wireshark中打開這個新文件。
顯示當前和前一個包之間的時間差，只需添加time delta列，如下:
選擇編輯|偏好|外觀|列
點擊+按鈕，將類型下拉改為“Delta Time”，標題改為“Delta”。
過濾請求的流量:
(tds。類型= = 0x01 || tds。類型= = 0 x03 | | tds。type == 0x0E)& tds。packet_number = = 1
上面的過濾器將顯示每個請求中的第一個TDS包，而Delta列現在將顯示上一次請求的最後一個響應包和下一個請求之間的時間。確保包是按“No”排序的。這將確保包按照發送/接收的順序進行。
導出為CSV，通過導航文件|導出包將|分解為CSV
在秒內計算應用程序的處理時間——在Excel中打開CSV，並在增量列中求和。
獲取近似的SQL處理時間:
重新打開步驟2中創建的文件。在Wireshark的上面，過濾器的流量只是響應:
tds。type == 0x04 && tds。packet_number = = 1
上面的過濾器將顯示每個響應中的第一個TDS包，而Delta列將顯示上一次請求的最後一個請求包和從SQL服務器發回的第一個響應數據包之間的時間。再次，確保包是由“No”命令的。”專欄。
導出為CSV，通過導航文件|導出包將|分解為CSV
在秒內計算SQL處理時間——在Excel中打開CSV，並在增量列中求和。
使用SQL分析器
雖然使用SQL Profiler收集診斷數據會增加您的工作流程，但它仍然可以為您提供處理時間的總體圖。您可以通過運行服務器端跟蹤來最小化這個開銷，然後按照下面的描述導出數據。或者，如果您對擴展事件和XQuery有信心，您應該能夠通過該路徑獲得類似的數據。
首先通過捕獲工作流的分析器跟蹤，只使用“標準(默認)”跟蹤模板。確保沒有其他的東西同時在數據庫中訪問，所以你只是在捕捉你的流量。
如果應用程序在本地運行時是快速的，那麽看起來您有網絡問題。此時，您需要知道應用程序和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中的捕獲:
使用過濾器:tds
點擊統計|對話，勾選“限制顯示過濾器”框。你應該在對話窗口中看到你的應用程序工作流對話。
使用的帶寬被顯示為“字節A -> B”和“字節B -> A”
在高延遲網絡上運行應用程序時重復捕獲，並再次查看所使用的帶寬。如果兩者之間存在較大的差異，那麽您可能會受到帶寬限制。
當然，為了進行準確的比較，您需要在兩個測試中運行SQL Server和在類似硬件上的應用程序。例如，如果SQL Server在不那麽強大的硬件上運行，那麽在給定的時間內它將在網絡上產生較少的流量。
根本原因分析
很有可能你有多重問題!但是，在完成上述步驟之後，您應該能夠考慮到花費在處理工作流上的所有時間。如果10秒的處理時間包含6秒的SQL處理時間、3秒的傳輸時間和1秒的應用程序處理時間，那麽您就知道如何優先考慮您的調查。
如果主要問題是緩慢的SQL處理時間，那麽有很多關於調優和跟蹤問題的信息。例如，由於我們已經捕獲了一個Profiler跟蹤，Gail Shaw的文章提供了一個關於如何在跟蹤中發現過程和批量的很好的概述，這些過程是導致性能問題的主要原因。此外，Jonathan Kehayias的書對於更深入地研究SQL Server中的常見性能問題是非常有用的。 相反，如果大部分時間都用於客戶端處理，那麽您可能需要考慮對應用程序代碼進行分析，以定位問題。有許多基於您的編程語言的分析工具(例如，for)。NET語言，您可以使用來自Redgate的螞蟻或來自JetBrains的dotTrace。
如果您正遭受網絡帶寬問題，那麽您可能需要限制請求的數據的大小。例如，當您請求數據時，不要使用“SELECT *”。只返回必要的列，並使用WHERE或過濾器只返回必要的行。
在我們的經驗中，性能問題的一個常見原因是在高延遲網絡上運行“chatty”應用程序。一個喋喋不休的應用程序可以發送許多重復的和不必要的查詢，使更多的網絡往返旅行比必要的多。
通常，這些應用程序最初是開發的，並部署到高速LAN，因此“chattiness”從來沒有真正造成問題。當數據移動到不同的位置，比如雲時，會發生什麽呢?或者是一個不同大陸的客戶試圖訪問它?或者您需要構建地理上多樣的災難恢復環境?如果你考慮到1ms LAN上的每一個查詢將會在60ms WAN上慢60x，你就會看到這是如何毀掉你的性能的。
簡而言之，在編寫客戶機/服務器應用程序時，您需要避免頻繁地執行相同的查詢，以最小化收集所需數據所需的往返次數。最常見的兩種方法是:
重寫代碼——例如，您可以在服務器上聚合和過濾多個數據集，以避免在每個數據集中生成查詢，盡管並不總是更改應用程序
使用查詢預取和緩存——有一些WAN優化工具可以做到這一點，但是它們有時很昂貴，而且很難配置來獲得高性能，而不會在應用程序中引入bug
在開發我們的數據加速器工具時，我們已經對這些問題做了大量的研究，並采用了一種方法，使用機器學習來預測您的應用程序將要做什麽，並預取所需的數據，以便在應用程序請求它時及時地準備好它。
總之
在你花費大量時間和金錢在一個可能的解決方案之前，確保你的問題已經解決了。我們已經看到公司花費大量的金錢和工時優化SQL查詢，當他們最大的問題是應用程序性能問題。相反，我們看到公司將越來越多的RAM或cpu投入到SQL服務器中，這將永遠無法彌補網絡延遲所增加的額外時間。如果您能夠確定工作流處理時間真正花費在哪裏，那麽您將以正確的方式指導您的時間和工作。
希望這給了你一些關於如何調查你自己的應用程序性能的想法，或者開始追蹤你可能有的問題。
翻譯 為什麽我的數據庫應用程序如此緩慢?