none
WidowsAzure環境とイントラ環境での通信速度について

    質問

  • お世話になります。

    現在、イントラ環境とAzure環境共にWCFのサービスを構築し、
    同じ内容のWsHttpBindingとWebHttpBinding(JSON)のWCFサービス環境とし
    これらについてデータ通信のパフォーマンスを計測しております。

    サーバ環境
    WCFサービス
    同一内容のWsHttpBindingとWebHttpBinding(JSON)のサービスを実装し、
    EntityFrameworkにてクエリを発行しデータを取得。


    サービスの実行環境
    ①Azure
    DB:SQL Azure

    ②イントラ
    DB:SQL Server 2008 R2(WCFサービスとは別のサーバー)
    WCFサービスのOS:Windows Server 2008 R2 Standard

    尚、インターネット接続との境界にプロキシー サーバーが存在します。

    クライアントの実行環境
    Windows XP Professional

    WCFクライアントからWCFサービスに
    ChannelFactoryを使用してプロキシクラスを事前生成せずにクライアントからサービスに接続し
    WsHttpBindingとWebHttpBinding(JSON)でなるべく同じ状態でデータを取得するためのテストプログラムを作成



    以下が、上記環境にて通信のパフォーマンスを計測した結果です。

    計測時間はサーバでの処理を省いたクライアントまでのレスポンス時間、
    (WCFサービスのメソッド開始からリターンする直前までの間の処理時間を省いた時間)
    WsHttpBindingでは14秒
    WebHttpBinding(JSON)では12秒
    とWebHttpBindingが約2秒ほど早い結果でした。

    同様の環境をAzureに置き換え計測したとろこ、
    WsHttpBindingでは33秒
    WebHttpBinding(JSON)では62.5秒
    と約30秒もWsHttpBindingが早くなり速度が大幅に逆転する結果となりました。


    そこで質問ですが、
    当方の計測では
    WsHttpBindingとWebHttpBinding(JSON)の通信方式でServerの環境により、
    通信速度が逆転してしまいましたがWebHttpBinding(JSON)はデータ量が少ないと考えているため、
    なぜこのような結果となっているかが見当がつきません、
    通信するうえでイントラ内のServer(Service)とWindowsAzure上のServer(Service)とでなにか考えられる違いがあるでしょうか?

    そもそもAzureはこのようなものなのでしょうか?

    もし以下の内容が原因だった場合はどのようにしたら確認できるでしょうか?
    ・どちらかのみデータが圧縮されている
    ・プロキシサーバなどでキャッシュされどちらかのしょりではその内容を取得している
    ・キャッシュに時間がかかっている
    ・通信経路が異なる

    どうかご教授いただければと思います。

    それではよろしくお願いします。



    2011年9月26日 11:20

回答

  • 懸案箇所を少しずつ切り分けていくのがよろしいかと思います。

    可能であれば例えば、Proxyを介さない環境やウイルスチェックソフトが入っていない環境でテストされてみては如何でしょうか?

    また、私の記憶が確かならば、Windows XPは通信スタックがナローバンドに最適化されていたと思います。
    最近のOS(Windows7/Vista等)はブロードバンドに最適化されていますのでそちらでテストしてみても同様かなど。
    (XPでもレジストリを変更することで最適化が可能です。設定変更用のフリーウェアなども色々あります)

    通信経路については、イントラではほとんどワイヤースピードだと思いますので、遅延等をほとんど考慮する必要が
    無いと思いますが、Azureはインターネット環境にありますので、環境を配置するデータセンターにもよりますが、
    通常、数10ms~数100msの遅延が発生します。また、お使いのWAN環境(回線など)の状況にも左右されるかと思います。

    今回かなり大きなデータを使って通信テストを行っているように思われますので、パケットの断片化や
    ラウンドトリップによる遅延の蓄積などが結果として表れているのかも知れません。
    この辺りの解析を行おうとすると、Fidderの範疇を超えますので、ネットワークモニター等が必要になります。
    (例えば、Microsoft Network Monitorなどがあります)

    また、お使いのインスタンスサイズに伴う通信回線容量の影響もあるかもしてません。
    (私の拙Blog記事に若干記述してあります。)

    通信データ圧縮については、AzureのWebRole(IIS or HWC)の標準設定では行われません。

    以上、ご参考になれば幸いです。

    2011年9月28日 1:23

すべての返信

  • 通信レベルでの確認をされたいという事であれは、Web Debugging ProxyのFidder等を利用されてみては如何でしょうか?

    2011年9月27日 0:06
  • ご教授ありがとうございます。

    Fiddlerを利用して通信状況を確認しおりますが、どうしてこのような結果となっているか理由がつかない状況です。

    Fiddlerを利用する場合どういったか所を確認すれば効果的か、もしご存知でしたらご教授いただければ幸いです。

     

    また、そもそも外部のサーバーと通信する場合にWebHttpBinding(JSON)での通信などの場合は

    ウイルスバスターなどでチェックが入って遅くなることなどは考えられるでしょうか?

    イントラ内ではウイルスバスターのコーポレートエディションが動いています。

    2011年9月27日 0:31
  • 懸案箇所を少しずつ切り分けていくのがよろしいかと思います。

    可能であれば例えば、Proxyを介さない環境やウイルスチェックソフトが入っていない環境でテストされてみては如何でしょうか?

    また、私の記憶が確かならば、Windows XPは通信スタックがナローバンドに最適化されていたと思います。
    最近のOS(Windows7/Vista等)はブロードバンドに最適化されていますのでそちらでテストしてみても同様かなど。
    (XPでもレジストリを変更することで最適化が可能です。設定変更用のフリーウェアなども色々あります)

    通信経路については、イントラではほとんどワイヤースピードだと思いますので、遅延等をほとんど考慮する必要が
    無いと思いますが、Azureはインターネット環境にありますので、環境を配置するデータセンターにもよりますが、
    通常、数10ms~数100msの遅延が発生します。また、お使いのWAN環境(回線など)の状況にも左右されるかと思います。

    今回かなり大きなデータを使って通信テストを行っているように思われますので、パケットの断片化や
    ラウンドトリップによる遅延の蓄積などが結果として表れているのかも知れません。
    この辺りの解析を行おうとすると、Fidderの範疇を超えますので、ネットワークモニター等が必要になります。
    (例えば、Microsoft Network Monitorなどがあります)

    また、お使いのインスタンスサイズに伴う通信回線容量の影響もあるかもしてません。
    (私の拙Blog記事に若干記述してあります。)

    通信データ圧縮については、AzureのWebRole(IIS or HWC)の標準設定では行われません。

    以上、ご参考になれば幸いです。

    2011年9月28日 1:23
  • たびたび、ご教授ありがとうございます。

    コンプライアンス上同一プログラムでの確認はできないかもしれませんが、

    一度Proxyを介さない環境でテストを実施してみたいと思います。

    また、教えていただきました情報を参考にネットワークモニターを行って確認するなど進めたいと思います。

     

     

    2011年9月29日 8:18