none
VB.NETからのSQLServerへの通信 RRS feed

  • 質問

  • VB.NETでSQLServerを使って開発を行っています

    SQL Server とクライアントの通信は、プログラムでは .NET のクラスを使用しています。SqlConnection を利用しています。

    WAN経由で利用しているので若干遅くなっていますが、回線は同じでもサーバとの距離によってかなり

    処理速度が変わってしまいます

    これは、どういった理由でそうなってしまうのでしょうか?

    TCP/IPでの通信を行っていますが、OSI標準モデルの第五層のプロトコルが何か教えていただけないでしょうか?

    もしくは、遅くなってしまう理由があればそれを教えていただけないでしょうか?

     

    2011年10月13日 3:58

回答

  • 上記の接続の場合、OSIの第五層はネットワークのハードによってかわるという認識であっていますでしょうか?

    ハードによって変わるということはなく、ハードとは独立しています。ハードの話が出てくるのは一般的に第3層のL3スイッチまででしょう。
    また、SQLは第5層のプロトコルとして考えられているようです。ハードが変わったらSQLが変わるということはありませんから、第5層がハードによって変わるということはありません。

    例としてあげられるものがあれば教えていただけるとありがたいです

    ハードとの関わりでしたら、

    OSI 7階層モデル 
    http://www008.upp.so-net.ne.jp/mkusanagi/network/osi.htm

    の、

    ■ 各層に該当するプロトコルと機器

    が参考になると思います。

     


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/
    • 回答としてマーク usksawa 2011年10月19日 7:04
    2011年10月19日 4:42

すべての返信

  • 回線の帯域や使用状況も同じなのでしょうか?ゲートウエイやルーターの設定などによって遠回りしている可能性もあります。tracertコマンドで一度トレースを取ってみられてはいかがでしょうか?

     


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/
    2011年10月13日 4:14
  • > TCP/IPでの通信を行っていますが、OSI標準モデルの第五層のプロトコルが何か

    TCP/IP は OSI モデルに準拠していないのではなかったですか?

    それはおいといて、第5はハードウェアに何を使っているかによって変わるので、広域ネットワークのノード間を語るには意味がないと思います。 サーバとクライアントの間に使われているすべてのハードウェア(場合によってはケーブルの種類まで)をあげないと、答えはでませんよね?

    「距離」というのが何をしめしているかはっきりしないのですが、ざっくりとはサーバとクライアントの間で「帯域幅」と「遅延時間」と「再送頻度」がすべて同じであれば、おなじようなレスポンスになることが期待できます。

    ネットワークの調査が難しい場合、「処理速度」が具体的に何の速度なのかわからないので、「接続時の応答に時間がかかる」とか「データ抽出時の取得処理に時間がかかる」とか、そういった具体的に遅くなる要素がなになのかをつきとめると、疑うべきところを類推できるようになるかと思います。

     

     

    2011年10月14日 3:53
  • みなさん、回答ありがとうございます

    ネットワークに無知で申し訳ありません

    解決方法は、おそらくアドバイスいただいたようなことをやっていかないといけないとは思っています

     

    VB.NETとSQLServer間の通信の詳細がわかれば教えていただければと思います

    TCP/IP接続ではあるのですが、それ以外に何か詳細のプロトコルがわかれば教えていただけると

    助かります

     

    2011年10月14日 5:14
  • うーん、TCP/IPの上で独自実装しているものに関して何をお調べになりたいのでしょうか……

    プロトコル云々ということであれば、まずは接続文字列をにらめっこしてみてください。

    若干遅い、とか処理が違うなどのイメージがちょっとわかりくいです。

    接続に関しては、以下の資料あたりのことは既知ということよろしいのでしょうか?

    「ネットワーク プロトコルの選択」
    http://technet.microsoft.com/ja-jp/library/ms187892.aspx

    「SQL Server Native Client での接続文字列キーワードの使用」
    http://technet.microsoft.com/ja-jp/library/ms130822.aspx

    2011年10月14日 6:10
  • 回答ありがとうございます

    全く、無知で申し訳ありません

    知りたいのは、上記の環境で東京にサーバがあり、関西と九州で同じハードで同じデータをアクセスした際、

    レスポンスに差があったことが発端で、ネットワークの問題であると思われるのですが、それを実証するために

    接続情報の詳細が欲しいと思っています

    それが接続するプロトコルによって距離がレスポンスに影響するかどうかを知りたいと思っています

    直接プログラムを開発しているわけではないので細かいことは確認しないと分かりませんが、

    確認すべきことがあれば教えて下さい

     

    2011年10月18日 0:25
  • 関西と九州の距離の差を気にしていらっしゃるのであれば、そこは大きな問題ではありません。その距離が大きな意味を持つのであれば、海外のサーバーからのレスポンスはいずれも悪いことになります。
    距離というよりは、回線の帯域、速度、スイッチなどのハードウエアの性能やその段数などが大きく関わってきます。その辺りをトータルで調査する必要があります。思った速度が出ていないと感じられるのでしたら、一度通信業者に調査を依頼されるのが良いと思います。

     


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/
    2011年10月18日 0:59
  • プロトコルそのものは距離というより、trapemiyaさんのご指摘の通りです。
    #距離という物理の話であれば、TCP/IPの上に乗っけているのであれば、TCP/IPに依存するためそんなに有意な差は出てきません。

    途中経路のネットワーク機器がフラグメントを起こしているかどうかなどのより低レベルレイヤの話になるため、あまり上位層プロトコルが関係するということはありません。
    ネットワークキャプチャを行うということであれば、認証がらみでの応答速度とか、フラグメントが発生していないかどうかなどをご覧ください。

    プロトコルが問題になることがるとすれば、認証や名前解決の問題で、例えば応答等が速い側には認証サーバーと名前解決のサーバーがあり、遅い拠点ではないなどが考えられます。

    それ以上の詳細は、サーバー配置図、途中経路の危機配置図、ネットワーク配線図、接続状況を総合的に判断しないといけないため、掲示板でのやりとりではなかなかわかりにくいと存じます。

    徹底的に調査するのであれば、拠点間のキャリアの口での計測や、各ネットワーク機器を挟んだときのキャプチャリングなどをしないと状況依存がひどすぎて一般的に公開できるような資料はないと存じます。

    2011年10月18日 2:23
  • trapemiyaさん、Chukiさん回答ありがとうございます
    プロトコルとレスポンスの関係はなんとなくわかりました
    ちなみに
    上記の接続の場合、OSIの第五層はネットワークのハードによってかわるという認識であっていますでしょうか?
    例としてあげられるものがあれば教えていただけるとありがたいです
    2011年10月19日 1:34
  • 各層は独立しているので、ネットワークのハードによって勝手に変えられること言うことはないですよ。
    電話で日本語というプロトコルを話す人どおしの通話で、途中の機器が勝手に英語に変換したら困りますよね?
     
    各層でパッケージされた内容を下位層がどうやって運ぶかだけの違いですから、速さや効率が変わることはあっても違う層に影響を与えることはありません。
    #違う層に階層に影響を与えないからこその階層化です。
     
    たとえば、フラグメントが発生し、下位層で小包の分割とか詰め直しなどということは発生します。これは、上位層で梱包された小包(パケット)を運ぶとき、小さいトラックでバラバラに発送するとか、貨物列車で拠点間を一気に運ぶとかの影響です。
    イメージとしては、下位層の種別(たとえばトラック使うとか、飛行機使うとか)とかルータの効率(荷捌き場の手際よさとか作業員の能力)とか、回線の品質(道路の整備状況が悪くてノロノロ運転しないといけないとか)などで届く速度が変わってきたりします。(あくまで、パケットを運ぶ速さの問題であり、プロトコルの問題ではありません)
     
    ちなみに、くどいようですが、プロトコルの効率の違いはありますが、これは一般的に距離によって変化する類のものではありません。
    距離に関連するのは、あくまで小包を運ぶときの問題であり、小包をどう梱包してあて名書きするか(つまりプロトコル)ではあまり影響しません。
    #TCP/IPの上で動作するプロトコルを選択しているのですから、さらに下位層がTCP/IPより上位層に影響を及ぼすことは基本的になく、純粋にTCP/IPの転送効率になります
     
    >上記の接続の場合、OSIの第五層はネットワークのハードによってかわるという認識であっていますでしょうか?
    >例としてあげられるものがあれば教えていただけるとありがたいです
     
    出入りの業者などのパートナーさんはどのような意見をおもちですか?
    具体例や認識の確認などは、有料のサポートかコンサルテーションしてもらった方が速いように存じます。
    質問者さんがどのような認識なのかはわかりませんが、文章だけ見ると正直な感想は「?」です。
    なぜ下位層が上位層のプロトコルを変えてしまうのか、私には理解できませんでした。
    「速度」なら変わるかもしれませんが、この辺りの述語や目的をを的確に掲示板で表現し伝えきるのは大変なため、他の手段で意思疎通できるサポート契約をお勧めします

    • 編集済み ChukiMVP 2011年10月19日 2:31
    2011年10月19日 2:21
  • > OSIの第五層はネットワークのハードによってかわるという認識であっていますでしょうか?
    > 例としてあげられるものがあれば教えていただけるとありがたいです

    私があげた話ですか? ちゃんと読んでいますか?

    「TCP/IP」は OSI モデルに準拠していないので、それを大前提として一般的な TCP/IP と OSI モデルへの対応では、5層は電送形式を割り当てることが多いです。具体的な例としては、経路上に存在する HUB や Rotuer のようなハードウェア機器が半二重か前二重かによって電送方式が変化します。

    「SQL Server の使用しているプロトコルの OSI モデル」であれば、5層はハードウェアに依存せず「TCP/IP」で固定です。

    2011年10月19日 3:32
  • 上記の接続の場合、OSIの第五層はネットワークのハードによってかわるという認識であっていますでしょうか?

    ハードによって変わるということはなく、ハードとは独立しています。ハードの話が出てくるのは一般的に第3層のL3スイッチまででしょう。
    また、SQLは第5層のプロトコルとして考えられているようです。ハードが変わったらSQLが変わるということはありませんから、第5層がハードによって変わるということはありません。

    例としてあげられるものがあれば教えていただけるとありがたいです

    ハードとの関わりでしたら、

    OSI 7階層モデル 
    http://www008.upp.so-net.ne.jp/mkusanagi/network/osi.htm

    の、

    ■ 各層に該当するプロトコルと機器

    が参考になると思います。

     


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/
    • 回答としてマーク usksawa 2011年10月19日 7:04
    2011年10月19日 4:42
  • trapemiyaさん

    面倒な質問ばかりですみません

    ハードとは関係ないとしたら、第三層がIP、第四層がTCP、第五層がSQLという

    イメージでよいということでしょうか?

    第五層のプロトコルででてくるのが、HTTP,FTP,POP, SMTP,Telnet等ですが

    これの一種としてSQLがあると認識しても問題ないでしょうか?

     

    2011年10月19日 7:06
  • それで問題ありません。以下、ざっと検索してみました。

    (参考)
    OSI参照モデルとTCP/IP
    http://www.nec.co.jp/octpower/seminar/languide/01_003.html

    レイヤ5 - セッション層 : Session layer
    http://homepage1.nifty.com/pokke/pdocs/pd4.html

    参考書関係
    第1章/インターネットワーキング
    セッション層
    http://tatsuya.info/pukiwiki/?Cisco%20Networking%20Academy%2FCCNA%C2%D0%BA%F6%20%A4%DE%A4%C8%A4%E1

    初心者にも理解できるネットワーク技術 NO.6 ~OSI参照モデル~
    ○第5層 セッション層
    http://melma.com/backnumber_116760_234852/

     


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/
    2011年10月19日 7:17
  • うーん、OSI 7階層とTCP/IP(いわゆるDoDモデル)とは峻別しておいた方がよいと思いますが……。
    #欧州と米国のつばぜり合いにつきあうつもりはありませんが^^;

    紹介いただいている記事あるとおり、DoDモデルでは、TCPより上はアプリケーション層としておいてますし、インターネット層以下はインターネット層のインターフェースに合わせてねくらいの定義です。
    CISCOさんはDBにアクセスするアプリケーションだよね、と扱っているのだと思いますが、開発屋さんへSQL Serverに接続するときに「プロトコルなあに」「SQLだよ」って答えたら困った顔をされると思います。やはり、モデルの概念が違うのに無理矢理マッピングすること自体が強引なので、微妙な齟齬が出てしまうと思います。

    アプリケーション層に当たるアプリケーションはDBクライアントであり、VB.NETでパフォーマンステストについて話すなら、「プロバイダ」と「プロトコル」の組み合わせになるのかなぁ、とか思っています。(←で、どの道TCP/IPを使うので、あまり違いがでないと思われますので初めに戻る)
    #たぶん私が第5層はなんですかと質問をされたら、プロトコルとして「名前付きパイプ」を選択したときは「名前付きパイプ」、「TCP/IP」を選択した場合は「うーん、敢えて言うなら、Socketを使ってTCP/IPで直接通信してる」と答えそうな気がします。


    • 編集済み ChukiMVP 2011年10月19日 9:37
    2011年10月19日 9:02
  • CISCOさんはDBにアクセスするアプリケーションだよね、と扱っているのだと思いますが、開発屋さんへSQL Serverに接続するときに「プロトコルなあに」「SQLだよ」って答えたら困った顔をされると思います。

    確かにそうだと思います。同じ言葉でも捉える人によって異なりますので、どうしてもこの辺りはあやふやになる気がします。「プロトコル」という言葉から何を思い浮かべるかのような気もします。一般的に「プロトコル」にSQLは入らないと答える人が多いと思いますが、OSI7階層に当てはめれば、広い意味で「プロトコル」に含めてもおかしくないのかな、とは個人的には思っていますが・・・。そういう意味で、SQLは「広い意味で」プロトコルに入ると訂正させて下さい。

     


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/
    2011年10月19日 10:04
  • >trapemiyaさん:SQLは「広い意味で」プロトコルに入ると訂正させて下さい。
    日本語の挨拶「もしもし」とかですらプロトコルなのですから、おっしゃる通りです。
    差し出がましい老婆心、申し訳ございませんでしたm(_ _)m。

    >usksawaさん
    僭越ながら、掲示板で質問する際には以下のあたりを記述すると、より知りたい内容が得られると思います。

    ・何のために情報を収集しているのか:(業者へ質問する前の調査、自分で問題解決、お勉強 etc.)
    ・集めた情報をどう使うのか:(業者へ質問するための情報提供、調査するための事前資料、レポートラインに報告するための資料作成 etc.)
    ・現在の調査状況:(VB.NET内で使用しているプロバイダやプロトコルの設定状況、調査して疑問やわからなかった点 etc.)
    ※要は、、「何が分からなくて知りたい」のか、「なんで知りたいのか」が分からないと、掲示板では答えようがないため、そういった質問には有料の対面サービスをお勧めする回答者の方が多いと存じます。(有料のサービスであれば、聞き取りから切り分けまでやってくれます。掲示板で同じことをしようとすると、スレばっかり伸びてそのうち回答者同士の議論が始まってあらぬ方向へ進んでいきます(回答者側は結構楽しいのですが、質問者さんの役に立つかは……反省orz))

    【蛇足(長文失礼)】
    厳しい言い方ですが、目的が、「自分で問題解決」だとすると、OSIとかプロトコルなどの書き込みを見る限り、調査、勉強から始めて1年は何が問題なのかすら見えてこない程度の、原因がみつけにくい障害なのではないかと思っています。
    #特定拠点だけ遅い、という報告が上がってくると、いつも背筋が凍りつきます
    たぶん、気づいてみれば、途中経路のルータの設定がおかしかったとか、館内のケーブルが断線しかかっていたとか、ハブの特定ポートが死にかかっていた、とか、しょうもない物理的な問題のような気がしています。
    (上記は、アルアルに出てくるだけで実際には遭遇しにくそうに見えて、私程度のプロ初心者でもすべて経験済みです。現場に乗り込んで片っ端からキャプチャリングしないと気付けないこともorz)。
    逆に、アプリやソフトウェア的な問題だったことは少ないように思います(認証系や名前解決サーバの配置や展開を失敗していた場合は除く。これらは結構時間がかかります。DNS Clientサービス止めていたおかげで毎回DNSに問い合わせにいってすごく遅かった、というのもありました。)。
    アプリの問題であった場合は、だいたい拠点にかかわらず遅くなるとか、リモート越しの拠点は全滅になって青ざめるパターンがほとんどです。

    【ご参考】
    「Wiresharkでネットワーク・プロトコルを解析する(基本操作編) - @IT」
    http://www.atmarkit.co.jp/fwin2k/win2ktips/1045wshark/wshark.html

    2011年10月20日 2:24
  • >trapemiyaさん:SQLは「広い意味で」プロトコルに入ると訂正させて下さい。
    日本語の挨拶「もしもし」とかですらプロトコルなのですから、おっしゃる通りです。
    差し出がましい老婆心、申し訳ございませんでしたm(_ _)m。

    いえ、とんでもないです。私の誤りを正していただいて、大いに感謝しております。
    何度も書いていることですが、私がこのフォーラムへ参加している基本的なスタンスは、一緒に勉強させてもらっているということですから(MVPになった後でも変わっていませんし、回答することも自分にとっては勉強になります)、今後ともいろいろなご意見、ご指摘などをいただけると喜びます。一つの問題を皆が知恵を出してより良い回答に結び付けば良いと思っていますし、それは恐らくそこに参加した全員にとって、大小の違いはあれ自分を高めることにつながると思います。

     


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/
    2011年10月20日 3:16
  • > 僭越ながら、

    たぶん、前半に書かれている

    > ネットワークの問題であると思われるのですが、それを実証するために
    > 接続情報の詳細が欲しいと思っています
    > それが接続するプロトコルによって距離がレスポンスに影響するかどうかを知りたいと思っています

    という話だと思います。この内容からすると、接続文字列で TCP/IP を指定していれば TCP/IP が使われます…で充分なレベルの話に見えます。最初の投稿にかいていますが、

    > ざっくりとはサーバとクライアントの間で「帯域幅」と「遅延時間」と「再送頻度」がすべて
    > 同じであれば、おなじようなレスポンスになることが期待できます。

    といったところしか提案しようがないと思うのですよね。「帯域幅」「遅延時間」「再送頻度」といった要素の違いに影響を受けるのが TCP/IP なので、拠点間にこれらの違いがないかを確認してみてください、ってことですね。

    > 認証系や名前解決サーバの配置や展開を失敗していた場合は除く

    ネットワークを疑う前に、このあたりは事前にチェックが必要ですね。名前解決にかかる時間に1分の差があれば、ネットワークがまったく同じ程度のレスポンスを返していても、アプリケーションのレスポンスは1分の差が発生しますし。

     

    2011年10月20日 4:06
  • 回答を頂いた皆様

     

    無知な私の質問に回答いただきまして、ありがとうございます

    ネットワークの詳細の情報は、お客様でやられているのでお客様に確認して

    もらいます

    これまでにいただいた、アドバイスを元に解決に向け、進めていきたいと思います

    ありがとうございました

    2011年10月21日 1:02