Derik Whittaker

Syndication

News


Don’t Kid Yourself, Size Does Matter…Least when talking about Web Service Messages

Ok, now that I have your attention, it is time to get your mind out of the gutter and back on the topic at hand.  When you are building out native mobile applications you are undoubtedly going to communicate to some sort of back end server via some sort of Web Service (say WCF for example if building on top of the Windows Phone 7 platform).

When build these web service endpoints most developers will pay attention to the type and the amount of data which is being sent across the wire, but I would venture a guess that for the most part they are doing this for the wrong, yet still very valid, reason.   I know in the past when I have build out endpoints and the payloads they were going to be communicating I was solely focused on making sure that only the minimum data points which are needed by the consumer are being sent.  As valid as this is, you should also concern yourself with the actual payload size in kilobytes which is being sent.  Which in my opinion is the right reason to pay attention to the data being sent across the wire.

Why should you focus on the size of the message more so than the content of the message?  Well by focusing on the size you will be indirectly focusing on the content as well but you will be doing so from a different perspective. 

Things you can do to reduce the payload size?

  • Use JSON rather than xml based web services:

    In my experience if you can encode (format) your payload as JSON you will see a size reduction of 40% or MORE in your payload.  And when we are talking about sending data across the wire (aka the cell network) this can and will have a huge impact on your applications performance.
  • If you use XML, make sure you use concise property names:

    When you build out your object model try to use concise rather than verbose names for properties.  For example if you have an object called Customer there is no need to name a property CustomerFirstName but rather I would suggest you call it First.  First the ‘Customer’ prefix should be inferred from the object context and the suffix of name should also be inferred.  By removing Customer and Name you are actually saving 24 characters, not 12.  Remember w/ XML you have the closing tag so the serialized message will be <First>Something</First> rather than <CustomerFirstName>Something</CustomerFirstName>.

    If you pay attention to this convention you could see as much as a 20-25% reduction in your message.  But word to the wise, I would still prefer readability over a super reduction in size.  There are a few blog posts out there that would suggest you name the property something like ‘F’.  Personally I think this obfuscates the intent of the message too much and this trumps a smaller message, but each scenario is unique and maybe you need that level of reduction in size.
  • If you use XML, make sure you control your namespaces of your objects:

    When you use WCF and DataContracts you have the ability to specify the namespace for each object.  In my experience the default namespace which is provided (the one of your physical object model) often times is very long.  In WCF you have the ability to specify a shorter namespace which can be used.  And when I specify this namespace I take the time to create it as a valid Uri rather than a object model namespace.  I have seen a 3-5% reduction in message size by doing this.  I know you are thinking that 3-5% is not much, but remember when talking about pushing data over networks such as Cell networks that can have a bit of an impact.

If you pay attention to your message from the size perspective and monitor this information you will be surprised by what type of performance gains you can receive.  This type of performance tuning is about the simplest and easiest you can perform and the ROI on it can be substantial.

Till next time,


Posted 05-17-2011 1:57 AM by Derik Whittaker
Filed under: , ,

[Advertisement]

Comments

remi bourgarel wrote re: Don’t Kid Yourself, Size Does Matter…Least when talking about Web Service Messages
on 05-17-2011 3:21 AM

About naming your field 'F' , it's also possible to use AutoMapper, and name our field like we want, This is one of the best way to reduce the size of the message.

Ayende Rahien wrote re: Don’t Kid Yourself, Size Does Matter…Least when talking about Web Service Messages
on 05-17-2011 10:20 AM

Derik,

I would <b>strong</b> disagree with you here.

What you need to do is use compression, and let the infrastructure deal with all the rest

Derik Whittaker wrote re: Don’t Kid Yourself, Size Does Matter…Least when talking about Web Service Messages
on 05-17-2011 10:27 AM

@Ayende,

Yes, compression is an option in some cases and I will update the post to reflect that.  However in some cases when using legacy services or services which you do not have much ownership of you cannot add in compression AFTER the fact.

James Manning wrote re: Don’t Kid Yourself, Size Does Matter…Least when talking about Web Service Messages
on 05-18-2011 10:12 PM

Ok, now I'm confused - so the scenario here is a service you have enough control over to specify JSON vs. XML and/or the xml namespaces and element names, but *not* enough control to enable compression?

IOW, I totally agree that there are legacy services where you just don't have the option of enabling compression, but I guess it's not clear to me how those scenarios would afford sufficient flexibility for the tips in the post?

Derik Whittaker wrote re: Don’t Kid Yourself, Size Does Matter…Least when talking about Web Service Messages
on 05-19-2011 12:32 AM

@James,

For the JSON tips there are many people who do not want to the overhead of compression or simply cannot support it because maybe they are hitting the web services via some javascript or the service is a legacy ASMX one or uses BasicHttp Bindings.  In these cases using JSON over XML will provide a huge ROI with very little effort.

For the XML Shortening tips maybe you do not control the setup or platform your consumers are running under so you cannot support JSON or Compression.  In these scenario’s using the shortening techniques would allow for a decent ROI without requiring the end consumer to do anything on their end to either support JSON or compression.

For the Compression tip (from Ayende) this is great if you have a new service and you control the consumers of the services.  

Long story short, the point of this post is less about how to reduce the size of the content of your messages but more about the idea that you MUST pay attention to the size of the messages in order to monitor performance.

Does this make sense?

James Manning wrote re: Don’t Kid Yourself, Size Does Matter…Least when talking about Web Service Messages
on 05-21-2011 5:21 PM

Gotcha, ok.  

I guess I'd expect that these days most 'modern' consumers would be adding Accept-Encoding to accept gzip, deflate (for instance, AFAIK a typical jQuery call will have since I believe the browser adds it on both 'normal' and XHR calls) so a typical provider would just make sure they have sane compression settings on the server side.  Of course, that's just my impression, not from actually looking at Fiddler traces. :)

I guess my hope was that people could/should focus on the object graph being sent, streaming/chunking/batching, but that the lower-level things like (de)serialization mechanisms were something that frameworks had evolved to the point where it Just Works for the common case. :)

Thanks!

Joshua Barker wrote re: Don’t Kid Yourself, Size Does Matter…Least when talking about Web Service Messages
on 07-24-2011 11:53 AM

If you have to use Xml, compression is definitely the way to go. However, IIS has very bad compression ratios and for compact framework projects, I've had great results with writing a custom soap extension using the Ionic.Zip library to do fast compression.

Even still, if you're trying to push a lot of data down, when it gets uncompressed, XML deserialization will be the slow factor.

For my current project I'm doing, I'm going to look at using marc gravell's .net implementation of google's protocol buffers called protobuf-net. It has a lot of promise and should be fast and lightweight.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)