INF: クライアントによる SQL Server スループットへの影響

文書翻訳 文書翻訳
文書番号: 180775 - 対象製品
この記事は、以前は次の ID で公開されていました: JP180775
この資料は、アーカイブされました。これは "現状のまま" で提供され、更新されることはありません。
すべて展開する | すべて折りたたむ

目次

概要

パフォーマンスに影響する一般要因を評価する場合、最も一般的に考慮されるのはプロセッサの処理速度、ディスク I/O、およびサーバー上のメモリです。このようなサーバー上の各部のパフォーマンスは正しいシステムパフォーマンスの実現に重要な部分ですが、ネットワーク保有時間やクライアント処理時間も、システムの全体的パフォーマンスに大きく影響する要因として考慮する必要があります。

この記事では、このネットワークやクライアントに関連する項目について解説し、これらの要因がサーバーにどう影響するかを評価するためのガイドラインを提供します。

詳細

この記事では、次のサンプルを使用します。この 2 つの接続手順では、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 コンピュータに対して次の 3 回のトリップが必要です。
  • トランザクション開始
  • 更新
  • トランザクションのコミット/ロールバック
接続 2 では、更新を完了するためのトリップが 1 回だけ必要です。

クエリのキャンセル

DB-Library と ODBC API は、どちらも非同期クエリ処理をサポートします。たとえば DB-Library では、dbdataready 関数を使って、クエリの完了状態のポーリングをクライアントに許可します。

DB-Library では、dbdataready 関数は DataReadySleep 値によってコントロールされています。DataReadySleep レジストリ キーの詳細については、Microsoft Knowledge Base の以下の記事を参照してください。
159234 : INF: How to Change the Sleep Value Used by Dbdataready

sleep 時間がタイミングに与える影響

特に指定しない限り、sleep 値は 250 ミリ秒です。

接続 1 で、SQL Server に対して 3 回のラウンド トリップがあります。特に指定がない限り、クライアントは、実際のネットワーク転送時間を除き、最低 750 ミリ秒待機させられます。待機時間の合計は (250 ミリ秒 * 3) = 750 ミリ秒となります。

接続 2 のトリップは 1 回で、待機時間は実際のネットワーク転送時間を除き、最低 250 ミリ秒です。

ただ Transact-SQL 構文を活用して 2 つのネットワーク ラウンド トリップを取り除くだけで、この例の処理速度を 3 倍速くすることができます。

ほかのユーザーに対するネットワーク ラウンドトリップの影響

接続 1 では、最低 500ミリ秒の間トランザクションがオープンされ続けます。トランザクションをオープンしてから 500 ミリ秒の間に更新を完了し、そしてトランザクションをコミットまたはロールバックします。データベースの同時実行性によって、修正中のレコードにほかのユーザーはアクセスできません。

接続 2 では、オペレーションの遂行に必要な時間だけトランザクションがオープンされます。133 MHz Pentium のシングル プロセッサ コンピュータで SQL Server と ISQL/w の両方が実行されている場合、次のようなタイミングになります。

Note: メモ 最後のネットワーク 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

前に説明したように、ネットワーク時間は単に 3 分の 1 になっただけです。しかし、この例が他のユーザーに与えるロックの影響は、16 分の 1 (532/32 = 約 16)になります。

この単純な例は、28.8 モデムで接続されたリモート ポータブル コンピュータを使用した場合の例です。dbdatareadysleep パラメータによって与えられる 250 ミリ秒の遅延に加えて、低速リンクによって情報が実際に送信される時間も無視することはできません。接続 1 では、データベースのほかのユーザーにさらに何倍もの影響が及ぶのに対し、接続 2 では基本的にクライアント コンピュータの処理速度によって影響されます。コマンドは一度だけ送信され、32 ミリ秒で SQL Server によって処理されます。処理速度が低下するユーザーは、予想されるとおり、低速モデムを使用するリモート ユーザーのみです。

クライアントのラグ時間

クライアントのラグ時間は、受け取った結果をクライアントが処理する間にかかる時間です。もう一度接続 1 を見てください。この接続がプロセスにどう影響するかがすぐにわかるはずです。クライアントでの結果セットの処理にさらに 10 ミリ秒必要な場合、トランザクション全体に 30 ミリ秒追加し、さらにトランザクションの待機時間として 20 秒追加されます。

次の例に切り替えてみましょう。これは、オンライン システムの在庫テーブルの例です。何か月もかかって、これまでにない最高速のオンライン発注処理システムを開発・設置したとします。ユーザーは検索、購入、ショッピング カートの確保ができ、その他のオプションも用意されています。これには、tbllnventory テーブルを使用します。
   tblInventory
      iProductID       int
      strTitle         varchar(50)
      strDescription   varchar(255)
      iSize            int
      iInStock         int
      iOnOrder         int
      iType            int

何かシリアルを購入したいと思いますが、何が利用できるでしょうか。シリアルはタイプ 2 に定義し、アプリケーションによって次のようなクエリが発行されます。この例では、データベースに 750 のシリアル関連アイテムがあります。
   Select strTitle, strDescription, iSize, iInStock from tblInventory
   where iType = 2

SQL Server によってクエリがコンパイルおよび解析され、結果が返され始めます。必要なページに共有ロックが取得されます。共有ロックによって、オペレーションの更新、挿入、および削除がブロックされることに注意してください。

同時に、このアプリケーションは全国で使用されているため、ほかに 6 人のユーザーがシリアルを注文しようとしています。

SQL Serverは、最初の表形式データ ストリーム (TDS) パケットにデータを挿入し、それをクライアントに送り、そしてクライアントが結果を処理するのを待ちます。クライアントが結果を処理する間 (クライアント待機時間)、SQL Server は処理されているページで共有ページ ロックを保持し続けます。この共有ロックによって、注文を完了しようとするユーザーをブロックします。

これは単純なアクションのように見えます。SQL Server から結果セットを select し、値をリスト ボックスに insert します。Pentium 133MHz を搭載するコンピュータであれば、1 秒で 750 アイテムをリスト ボックスに追加することができます。 挿入中 にリスト ボックスを無効にするには、わずか 3 分の 1 秒しかかかりません。リスト ボックスを無効にするだけで、クライアント待機時間を大幅に削減することができます。

また、select オペレーションを変更して、ロック時間をさらに短縮することもできます。クエリを次のように変更し、共有ロックのエクスポージャを制限します。
   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 Knowledge Base の以下の記事を参照してください。
165951 : INF: Result Processing for SQL Server

172117 : INF: How to Profile Transact-SQL Code in Stored Procedures and Triggers

162361 : INF: Understanding and Resolving SQL Server Blocking Problems

167610 : INF: Assessing Query Performance Degradation

48712 : INF: Handling Timeouts Correctly in DB-Library

117143 : INF: When and How to Use dbcancel() or sqlcancel()

詳細

この資料は米国 Microsoft Corporation から提供されている Knowledge Base の Article ID 180775 (最終更新日 1999-04-14) をもとに作成したものです。

プロパティ

文書番号: 180775 - 最終更新日: 2014年1月29日 - リビジョン: 3.1
この資料は以下の製品について記述したものです。
  • Microsoft SQL Server 6.5 Standard Edition
キーワード:?
kbnosurvey kbarchive ssrvgen kbhowto KB180775
"Microsoft Knowledge Baseに含まれている情報は、いかなる保証もない現状ベースで提供されるものです。Microsoft Corporation及びその関連会社は、市場性および特定の目的への適合性を含めて、明示的にも黙示的にも、一切の保証をいたしません。さらに、Microsoft Corporation及びその関連会社は、本文書に含まれている情報の使用及び使用結果につき、正確性、真実性等、いかなる表明・保証も行ないません。Microsoft Corporation、その関連会社及びこれらの権限ある代理人による口頭または書面による一切の情報提供またはアドバイスは、保証を意味するものではなく、かつ上記免責条項の範囲を狭めるものではありません。Microsoft Corporation、その関連会社 及びこれらの者の供給者は、直接的、間接的、偶発的、結果的損害、逸失利益、懲罰的損害、または特別損害を含む全ての損害に対して、状況のいかんを問わず一切責任を負いません。(Microsoft Corporation、その関連会社 またはこれらの者の供給者がかかる損害の発生可能性を了知している場合を含みます。) 結果的損害または偶発的損害に対する責任の免除または制限を認めていない地域においては、上記制限が適用されない場合があります。なお、本文書においては、文書の体裁上の都合により製品名の表記において商標登録表示、その他の商標表示を省略している場合がありますので、予めご了解ください。"

フィードバック

 

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