1

MessageSizeInspectorサービスがクライアントから受け取るメッセージのサイズを検査するクラスを作成しました。これは次のようになります。

//the actual implementation logs more!
//but in this question, my only concerns is request.ToString()
public sealed class MessageSizeInspector : 
            BehaviorExtensionElement,   //to enable it to be used in config
            IDispatchMessageInspector,  //service-side inspector
            IEndpointBehavior           //so we can apply it on endpoint
{
   if (request != null )
   {
      Logger.Verbose("Message = {0}\n", request.ToString()));
   }       
   //more  
}

そして、次の形式のメッセージをログに記録します。

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header>
    <To s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">http://localhost:8961/EngineService</To>
    <Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">http://tempuri.org/IEngineService/GetMousePatternID</Action>
  </s:Header>
  <s:Body>
    <GetMousePatternID xmlns="http://tempuri.org/">
      <args>
        <accelerator xmlns="http://schemas.datacontract.org/2004/07/Runaware.Insight.EngineService" />
        <accessKey xmlns="http://schemas.datacontract.org/2004/07/Runaware.Insight.EngineService" />
        <controlId xmlns="http://schemas.datacontract.org/2004/07/Runaware.Insight.EngineService">66222</controlId>

        <!--- deleted the rest to avoid verbosity -->

      </args>
    </GetMousePatternID>
  </s:Body>
</s:Envelope>

ご覧のとおり、実際のメッセージは非常に小さいですが、XML 要素と名前空間のために非常に大きくなっています。特に名前空間は、実際のメッセージに比べて大きすぎます。

私の質問は、soapメッセージのサイズをどのように減らすことができるかということです。xmlnsすべての要素で同じであるため、WCF はこれを最適化できますが、そうではありません。選択した短い名前空間を使用するようにできますか? acceleratorandのような値のない要素はほとんどaccessKeyありませんが (右にスクロールするとわかります)、まだ存在しています! nullWCF でそれらを省略し、サービス側でそれらの値 (または既定値) を想定することはできますか?

要するに、帯域幅を節約するためにできることはありますか?

上記のメッセージが、まったく同じ形式で、同じ XML 要素と名前空間を使用してクライアントに送信されると想定しています。

サーバーは C# と WCF で記述され、クライアントはWindows Web Services APIを使用して C++ で記述されています。サービスとクライアントの両方が私によって書かれました。だから私はそれらを完全にコントロールしています。必要に応じて、帯域幅を節約するために変更することがあります。

4

4 に答える 4

1

うーん、私の最初のアプローチはWCF Compressionを使用することです。経験がないので、リンクを提供することしかできません。しかし、それはかなり良い改善になると思います。

質問は、クライアントに影響力を持っていますか。その構成も編集する必要があるためです。

編集：質問はコメントの1つで回答されています。:o)

于 2013-01-23T09:01:07.033 に答える
1

SOAP へようこそ。多くの人が無知によって遭遇する問題です。XML や SOAP も優れていますが、テキスト ベースの表現システムにはオーバーヘッドがあります。また、特に小さなメッセージの場合、帯域幅への影響が大きくなります。

できることは多くありません。IIS で外部圧縮を行ってから、soap/xml をドロップし、JSON を使用して Web API に移動します。Web servviec/soap の標準はかなり - うーん - 明示的であり、標準です。それをバイパスする (ドロップ要件、何か他のものを使用する) ことが、実際に対処する唯一の方法です。

于 2013-01-23T09:01:26.630 に答える
0

すべてを完全に制御できるので、代わりにWebAPIを使用するように変更してみませんか?

最終決定を下す前に、次の質問をご覧ください。ASP.net Web API を使用できる場合、WCF が必要ですか?

于 2013-01-23T08:59:54.647 に答える