CODEWITHSUNDEEP
c#wcfservicebandwidth
Sarfaraz Nawaz
Sarfaraz Nawaz

Reputation: 361262

How to reduce WCF soap message size to save bandwidth?

I've written a MessageSizeInspector class to inspect the size of the messages the service receives from the client. Here is what it looks like:

//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  
}

And it logs message of this format:

<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>

As you can see the actual message is tiny, but the XML elements and namespaces make it too huge. Namespaces, in particular, are too big in comparison to the actual message.

My question is : how can we reduce the size of the soap messages? As the xmlns are same for all elements, the WCF could optimize this but it doesn't. Can we make it use shorter namespace of our choice? There are few elements such as accelerator and accessKey which do not even have any value (as you can see by scrolling right), but they're still there! Can we make WCF to omit them and assume their values null (or default value) on the service side?

In short, anything we can do to save bandwidth?

I'm assuming that the above message is what comes the client, exactly in the same format, with same XML elements and namespaces.

The server is written in C# and WCF, and the client is written in C++ using Windows Web Services API. The service and client both written by me. So I've full control over them. If required, I may change it to save bandwidth!

Upvotes: 1

Views: 2684

Answers (4)

I&#250;ri dos Anjos
I&#250;ri dos Anjos

Reputation: 381

Aside from the anwsers that the others already said (eg: WCF compressing)...

Try setting Name and Namespaces on DataContracts, DataMembers as well as ServiceContracts.

Example:

 [DataContract(Name = "a", Namespace = "")]
 class Person
 {
     [DataMember(Name = "a")]
     public string FullName;
     [DataMember(Name = "b)]
     public int Age;
 }

This will make Person to be called as "a" from namespace "" and the property FullName to be called as "a", making the XML shorter like:

<a> -- Represents the Person class
    <a>Name of the person</a> -- Represents the FullName property
    <b>38</b>
</a>

Properties and classes must have different "short" names from DataContract and DataMembers.

Reference: https://bkiener.wordpress.com/2010/05/04/optimize-data-contracts-for-better-wcf-performance/

Upvotes: 2

TomTom
TomTom

Reputation: 62093

Welcome to SOAP and the problem many people meet with ignorance. XML is nice, SOAP too, but there IS an overhead of having a text based expressive system. And the bandwidth hit is hugh, especially for small messages.

THere is not a lot you can do - outside compression in IIS and then dropping soap / xml and go web api with JSON. The web servviec / soap standard is quite - hm - explicit and a standard. Bypassing it (drop requirement, use something else) is the only way to really deal with it.

Upvotes: 1

DHN
DHN

Reputation: 4865

Hmm, well my first approach would be to use WCF Compression. I can only give you the link, because I've no experience with it. But I assume, that it would be a pretty good improvement.

Question is, do you have influence on the client. Because its configuration must also be edited.

Edit: Question is answered in one of your comments. :o)

Upvotes: 1

Tom Chantler
Tom Chantler

Reputation: 14931

Since you have full control over everything, why not change to use WebAPI instead?

Take a look at this question before you make your final decision: Do I need WCF if I can use ASP.net Web API

Upvotes: 0

Related Questions