INF: 用戶端效果上 SQL Server 輸送量

文章翻譯 文章翻譯
文章編號: 180775 - 檢視此文章適用的產品。
本文已封存。本文係以「現狀」提供且不會再更新。
全部展開 | 全部摺疊

在此頁中

結論

在評估會影響效能的一般區域,最常視為方面是處理器速度]、 [磁碟 I/O,] 和 [在伺服器的記憶體。 雖然這些部分伺服器的效能有適當的效能的關鍵,您還必須考慮網路延遲與用戶端處理時間,作為對系統的整體效能也有重大影響的因素。

這篇文章討論後者的區域,並提供方針評估它們可能會在伺服器有什麼影響。

其他相關資訊

下列範例將使用整份文件。兩個連線的步驟執行只是一個小型的差異 Transact-SQL 語法中使用相同的更新。

連接 1

use pubs
go
select convert(char(30), GetDate(), 9) "Start Time"
go

            Begin transaction

   Go   ==>   Send to SQL Server and process results

            Update authors set au_lname = au_lname

   Go   ==>   Send to SQL Server and process results

Commit / Rollback transaction

   Go   ==>   Send to SQL Server and process results

select convert(char(30), GetDate(), 9) "End Time"
go
				

連線 2

use pubs
go
select convert(char(30), GetDate(), 9) "Start Time"
go
begin transaction
if(0 = @@ERROR)
begin
   update authors set au_lname = au_lname
   if(0 = @@ERROR)
   begin
      commit transaction
   end
   else
   begin
      rollback transaction
   end
end
go    ==>   Send to SQL Server and process results
select convert(char(30), GetDate(), 9) "End Time"
go
				

網路往返

連線 1 需要三個旅遊到 SQL Server 電腦:
  • 開始交易
  • 更新
  • 認可 / 回復交易
連線 2 需要單一往返來完成更新。

查詢取消通知

資料程式庫和 ODBC API 都支援非同步查詢處理。比方說資料程式庫使用 dbdataready 函式允許用戶端輪詢完成狀態的查詢。

DB 程式庫中 dbdataready 函式是由 DataReadySleep 值所控制。取得更多資訊有關 DataReadySleep 登錄機碼請參閱下列的 「 Microsoft 知識庫 」 中的文件:
159234: INF: 如何變更 Dbdataready 使用 [睡眠值

睡眠時間會在計時的影響

預設情況下,睡眠值會為 250 毫秒。

1 的連線,讓 SQL Server 三個圓形的往返。預設情況下,用戶端會遇到 750 毫秒的等候時間的最小值不實際的網路傳輸計算時間。從計算等候時間 (250 毫秒 * 3) = 750 毫秒為單位)。

連線 2 讓單一來回存取時,遇到最小值為 250 毫秒的等候時間不計算實際的網路傳輸時間。

您可以變更這個範例的速度,第三個係數,只需利用 Transact-SQL 語法,並移除兩張網路往返。

網路往返如何影響其他使用者

連線 1 會保留交易開啟以供最小值為 500 毫秒。 交易已開啟之後花 500 毫秒以完成更新並接著認可或復原交易。資料庫並行可防止其他使用者存取您正在修改的記錄。

連線 2 保持交易為開啟狀態只為長視完成作業。133 MHz Pentium 單一處理器電腦上執行 SQL Server 與 ISQL/W,看過下列計時。

注意: 其中一個下列的範例中未顯示最終的網路 I/O。認可或復原已完成後鎖定被釋放,但不是處理最終的 I/O。
   Begin transaction                5 milliseconds
   Update                          20 milliseconds
   Commit/Rollback transaction      7 milliseconds
      TOTAL                        32 milliseconds
				

連線 2 將完成大約 32 (毫秒),而連線 1 需要較大的處理視窗,並大幅擴充交易延遲時間。
   Begin transaction                5 milliseconds
   Network I/O                    250 milliseconds
   Update                          20 milliseconds
   Network I/O                    250 milliseconds
   Commit/Rollback transaction      7 milliseconds
      TOTAL                       532 milliseconds
				

如先前顯示網路時間是三個簡單的因數。但是,鎖定此範例會對其他資料庫使用者的影響是 16 個係數 (532/32 = ~ 16)。

現在讓我們假設這個簡單的範例是來自以 28.8 數據機連線的遠端可攜式電腦。除了 250 毫秒延遲 dbdatareadysleep 參數所加諸,實際上透過慢速連結傳輸資訊的時間是 appreciable。連線 1 會由一個更大的因素影響其他資料庫使用者,而連線 2 會主要受到用戶端電腦的速度。 命令會傳送一次,處理在 SQL Server 32 (以毫秒為單位)。 遇到一個降低系統的唯一的使用者是遠端使用者是如預期由於以緩慢的數據機。

用戶端延隔時間

用戶端延隔時間是時間的當用戶端處理它收到結果時要經過內。如果您一次查看連線 1,您就可以快速查看如何這可能會影響處理序。如果用戶端處理結果集需要額外 10 毫秒,您可以新增另一個 30 毫秒到整體的交易時間和另一個 20 毫秒到交易延遲時間。

讓我們再次切換範例。在這種情況下是一個庫存資料表,從線上的系統。您花了幾個月開發和安裝何者應該歷程記錄的最快線上的訂單處理系統。使用者可以搜尋、 購買,並保留其他選項之間的一個購物車。這是 tbllnventory 資料表:
   tblInventory
      iProductID       int
      strTitle         varchar(50)
      strDescription   varchar(255)
      iSize            int
      iInStock         int
      iOnOrder         int
      iType            int
				

我想要購買某些 cereal。不過,我想要查看可用。我們可以定義 cereal 鍵入 2 時,使應用程式發出下列查詢。在這個範例資料庫中含有 750 cereal 相關項目。
   Select strTitle, strDescription, iSize, iInStock from tblInventory
   where iType = 2
				

SQL Server 將會編譯和剖析查詢,然後開始傳回的結果。共用的鎖定被取得適當的頁面上。請記住,共用鎖定區塊更新、 插入和刪除作業。

在同一時間因為您的應用程式用全國,六個其他人正嘗試要放置 cereal 訂單。

SQL Server 會填滿第一個的表格式資料流 (TDS) 封包、 將它傳送至用戶端並再等待用戶端處理結果。在時間用戶端處理結果 (用戶端的延遲時間) SQL Server 繼續持有共用的分頁鎖定在頁面上它已處理。此共用的鎖定可以封鎖使用者正嘗試要完成訂單。

它看起來像是一個簡單的動作。選取從 SQL Server 的結果集,並將其插入清單方塊中的值。133 MHz Pentium 電腦可以加入至清單方塊 750 項目,只是超過一秒內。停用清單方塊時歸檔它會採用只有三分之一的秒。只停用清單方塊,可以大幅減少用戶端的延遲時間。

您甚至可能會想變更選取作業,以進一步減少鎖定。藉由變更下列的查詢限制共用的鎖定曝光度。
   Insert * into #tblSelect from
   Select strTitle, strDescription, iSize, iInStock from tblInventory
				

   Select * from #tblSelect
				

查詢 SQL Server 上隔離,並不會啟動傳回結果,直到已移至暫存資料表,並從庫存資料表釋放所有的共用的鎖定。這會限制到所需的 SQL Server 將結果移至 tempdb 時間庫存資料表保持共用的鎖定的時間。控制項是一次與資料庫和不在用戶端。

完成類似行為的另一個方法是讓 「 智慧型 」 用戶端。 代替填滿清單方塊,可能會更快載入陣列。但是,您仍有疑慮結合之網路輸送量。暫存資料表是在這些情況下更好的解決方案。

您可以看到用戶端可以播放關鍵卷資料庫處理量。您應該特別小心處理遠端及報告系統時。在保留鎖定時處理結果所需的用戶端的時間量有可能會影響資料庫輸送量。這類問題可能難看出作為延遲期間可能計時 100 毫秒為單位而且不易使用 sp_who 預存程序查看。使用慢速連結來快速查看行為。從 RAS 連結執行應用程式,並查看其整體的行為是像。您也可以利用完整的 SQL 追蹤公用程式來仔細分析應用程式。

如需詳細資訊請參閱下列文件 「 Microsoft 知識庫 」 中:
165951: INF: 為 SQL Server 處理的結果

172117: INF: 如何在 [預存程序和觸發程序的設定檔 Transact-SQL 程式碼

162361: INF: 了解及解決封鎖問題的 SQL Server

167610: INF: 評估查詢效能降低

48712: INF: 處理 DB 程式庫中正確的逾時

117143: INF: 何時和如何使用 dbcancel() 或 sqlcancel()

屬性

文章編號: 180775 - 上次校閱: 2013年10月7日 - 版次: 3.0
這篇文章中的資訊適用於:
  • Microsoft SQL Server 6.5 Standard Edition
關鍵字:?
kbnosurvey kbarchive kbmt kbinfo KB180775 KbMtzh
機器翻譯
重要:本文是以 Microsoft 機器翻譯軟體翻譯而成,而非使用人工翻譯而成。Microsoft 同時提供使用者人工翻譯及機器翻譯兩個版本的文章,讓使用者可以依其使用語言使用知識庫中的所有文章。但是,機器翻譯的文章可能不盡完美。這些文章中也可能出現拼字、語意或文法上的錯誤,就像外國人在使用本國語言時可能發生的錯誤。Microsoft 不為內容的翻譯錯誤或客戶對該內容的使用所產生的任何錯誤或損害負責。Microsoft也同時將不斷地就機器翻譯軟體進行更新。
按一下這裡查看此文章的英文版本:180775
Microsoft及(或)其供應商不就任何在本伺服器上發表的文字資料及其相關圖表資訊的恰當性作任何承諾。所有文字資料及其相關圖表均以「現狀」供應,不負任何擔保責任。Microsoft及(或)其供應商謹此聲明,不負任何對與此資訊有關之擔保責任,包括關於適售性、適用於某一特定用途、權利或不侵權的明示或默示擔保責任。Microsoft及(或)其供應商無論如何不對因或與使用本伺服器上資訊或與資訊的實行有關而引起的契約、過失或其他侵權行為之訴訟中的特別的、間接的、衍生性的損害或任何因使用而喪失所導致的之損害、資料或利潤負任何責任。

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com