Options to shrink ASP.NET 3.5 XML documents returned from WebMethods

I've inherited an ASP.NET (.net 3.5) web app and the corresponding C# client components and a related javascript client.

The server-side components use the default [WebMethod] serialization and, given the size of some of our XML documents (and the ver开发者_StackOverflow社区bosity of the element names), I'm curious about options to shrink the size of the documents returned.

I'm open to binary XML, custom serialization of XML (e.g., change ThisVeryLongElementNameWhichShowsUpALot into something shorter), simple compression, moving to JSON, etc. We do have quite a substantial number of individual WebMethods and different objects returned, so the ideal solution would involve changing as little as possible on both sides of the equation.

I understand there will be a CPU/bandwidth tradeoff doing things like compression or custom serialization, so I'd like to benchmark some options without building a giant pile of code.

Could someone please point me at relevant documentation or IIS/VS.NET options to configure to explore these tradeoffs?

---

I recently tested IIS compression and was happy with the results, after I figured out how to set the compression level. The end result was a 196 kb JSON result compressed to 13.6 kb.

Below are some notes I made for myself on setting up dynamic compression and setting the compression level. I apologize if they are rough as I made them primarily for my own future reference.

In addition, I would definitely advise trying JSON over XML as it provides a much more compact result. I don't have specific numbers, but off-hand, my recollection is that JSON was around 50% smaller than XMl.

---

Install dynamic compression if necessary

Windows 7:

1. Open the Programs and Features console by going to Start > Control Panel > Programs and Features.
2. Click 'turn Windows features on or off'.
3. In the dialog, expand Internet Information Services > World Wide Web Services > Performance Features, and turn on Dynamic Content Compression.
4. Click Ok.

Windows Server 2008:

1. Open the Server Manager console by going to Start > All Programs > Administrative Tools > Server Manager.
2. In the Server Manager tree view, expand Roles, and click Web Server (IIS).
3. In the main window, scroll down to the Role Services panel, and click Add Role Services.
4. In the Select Role Services dialog, click and enable Web Server (Installed) > Performance (Installed) > Dynamic Content Compression.
5. Click Next.
6. On the Confirm Installation Selections screen, click Install.

Enable dynamic compression in IIS

1. In IIS management app, select the server, and in the IIS feature group, double click "Compression".
2. Check "Enable dynamic content compression".

Enable for "application/json" and "application/xml"

1. Find the applicationHost.config file in c:\Windows\System32\inetserv\config
2. edit it and find the httpCompression element.
3. Under <dynamicTypes>, add the following elements:

<add mimeType="application/json" enabled="true" />
<add mimeType="application/xml" enabled="true" />

Restart IIS.

To verify, check in Fiddler and make sure the 'Decode' button is not selected (the Decode button should be on the main toolbar). You should see that the response 'Content-Encoding' header shows 'gzip', and that the response is compressed:

Advanced Settings

Set the compression level using the following command (the default level is 0):

C:\Windows\System32\Inetsrv\Appcmd.exe 
    set config -section:httpCompression
    -[name='gzip'].staticCompressionLevel:9
    -[name='gzip'].dynamicCompressionLevel:4

See these sites for additional details:

Making the most out of IIS compression - Part 1: IIS 7 configuration

IIS 7 Compression. Good? Bad? How much?

My initial testing of a json response:

None:          196,416 bytes
Level 0:        35,234
Level 1:        29,219
Level 4:        18,461
Level 9:        13,638

---

You can decorate your classes, properties, and methods with attributes that tell ASPNET how to serialize. You have several options for producing "smaller" XML:

• for properties with VeryLongNames , use an [XmlElement] attribute and specify an alternative, shorter name. Any short element name will do, just make sure it is unique. Keep in mind that this reduces readability. XML is intended to be human-readable to make it easy to handle. <StudentUserId>19820</StudentUserId> has a clear meaning, while <u>19820</u> does not.

• if you don't mind going to a mixed model, you can serialize some simple quantities as attributes rather than elements. For example, for a simple integer value of 42, the text to serialize as an attribute is PropName='42', while the text to serialize as an element is <PropName>42</PropName>. So you can cut the size almost in half, regardless of the length of the name. Some people are religiously opposed to serializing into xml attributes. I never understood why that was verboten, so I think it is a good approach for squishing xml.

• There are some options for serializing arrays into XML. Use XmlArrayItem to produce a smaller form for arrays. see this MSDN article for more info.

Beyond using the attributes, there are some other things you can consider....

• check your XML messages to insure that you are serializing only what you need, and that what you serialize is not being serialized in an inefficient manner. For example, if you're transmitting a 32k binary image, it may be better to transmit an HTTP URL, and let the app do an additional request to get the image, rather than packing the image into the XML envelope. Or, use MTOM instead of XML serialization.

• consider optimizing some of your messages. Do you always need to serialize everything? Could you parameterize your webmethods to allow the caller to ask for more or less detail on each reply?

• Are you using XML namespaces effectively? Don't use multiple namespaces for no reason. It only inflates the size and complexity of the messages . On the other hand, if you have good reasons for using multiple xml namespaces, don't abandon those reasons in order to save space.

• consider if it is worth investing time and effort optimizing the XML payload size. What is the real payoff? If you spend 4 weeks optimizing and testing to gain 4% throughput, is it worth it? Could you do better by simply scaling out, or optimizing your network layout?