Performance: json vs xml

Topics: Web Api
Jan 31, 2012 at 6:47 PM

Hi,
I did a quick test while getting 200 times an entity (keeping HttpClient open) using application/json and application/xml.

The time taken is comprehensive of the deserialization process. Person is an entity with two strings, two ints and 1K byte array.

Test                 Operation       calls    seconds
-------------------------------------------------------
WebAPIjson      GetPerson       200     0,530
WebAPIxml       GetPerson       200     0,212

I know this is still a Preview release, but I would expect json to be more performant than xml. Furthermore a json scenario is getting more and more used in respect to xml.

Is this the expected behavior for the RTM?

thanks

Jan 31, 2012 at 7:00 PM

If you want a proper comparison of XML vs. JSON, you should use a custom formatter that leverages Json.NET.  The built-in JSON serialization is underwhelming and acknowledged as lacking.  If you search on this forum, you can find posts from the team saying as much.  Also, I don't know what your real payloads will look like but you might also consider using BSON if performance is a concern and your data lines up.

Jan 31, 2012 at 7:06 PM
Edited Jan 31, 2012 at 7:59 PM

I already use json.net for real-life scenarios but I am wondering how many people will do.

I really can't understand why the most used scenario in the world should be so slow in comparison to third-party libraries. Furthermore many companies have policies that require not using third-party libraries and I often have this problem in my work.

Regarding BSON, do you have any pointers?

Thanks

Feb 2, 2012 at 5:54 PM
Edited Feb 2, 2012 at 5:56 PM

I've found it is very dependent upon your message size.  The larger your transfer, the worse xml gets.

You'll find Xml becomes the largest payload. Json is nice, however doesn't easily support binary unless you base64 encode. Use Bson either as a replacement for Json or just for transferring your binary data.  For small message sizes, Bson will be larger than Json, but again, as your data increases, you'll notice a huge difference.

At work we recently wrote a content-sharing/subscription network to handle small-large transfers of binary data.  Almost all data is serialized via Bson and it's been working perfectly when used in conjunction with Json.NET

You can also take a look at protocol buffers by Google.

http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking

http://stackoverflow.com/questions/2000933/protocol-buffers-versus-json-or-bson

Feb 2, 2012 at 10:37 PM
dgdev wrote:

I've found it is very dependent upon your message size.  The larger your transfer, the worse xml gets.

You'll find Xml becomes the largest payload. Json is nice, however doesn't easily support binary unless you base64 encode. Use Bson either as a replacement for Json or just for transferring your binary data.  For small message sizes, Bson will be larger than Json, but again, as your data increases, you'll notice a huge difference.

At work we recently wrote a content-sharing/subscription network to handle small-large transfers of binary data.  Almost all data is serialized via Bson and it's been working perfectly when used in conjunction with Json.NET

You can also take a look at protocol buffers by Google.

http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking

http://stackoverflow.com/questions/2000933/protocol-buffers-versus-json-or-bson

I very much agree w/ this response.  dgdev, are you guys inspecting the data in order to determine how best to serialize it??  Does your formatter differ significantly from the Json.NET formatter in the contrib project?

Feb 3, 2012 at 4:07 PM

Thanks guys for the pointers and suggesions.

Test               Operation        calls  seconds
-------------------------------------------------------
basichttp       GetPersons      100      2,771
wshttp           GetPersons      100      1,319
net.tcp           GetPersons      100      0,833
net.pipe         GetPersons      100      0,848
RIAsoap         GetPersons      100    10,161
MVCjson        GetPersons      100    36,760
WebAPIjson    GetPersons      100      1,581
WebAPIbson   GetPersons      100      0,808
WebAPIxml     GetPersons      100      1,190

Notes:

  • WebAPIjson use json.net formatter by webapicontrib
  • MVCjson use default MS json formatter
  • WebAPI with default MS json formatter has similar (slow) performance than MVC-json
  • Lowering the byte[] blob to 200 bytes gives better timings but still huge difference with json.net

My concerns still remain regarding the usability of the json serializer in real-life scenarios.

Feb 5, 2012 at 7:16 AM
davidpeden3 wrote:
I very much agree w/ this response.  dgdev, are you guys inspecting the data in order to determine how best to serialize it??  Does your formatter differ significantly from the Json.NET formatter in the contrib project?

We were using Fiddler quite a bit throughout our research phase and in early development.  Here is our JsonNET formatter/extensions.

http://pastebin.com/affN0RxR

Also, check out StressStimulus for performance/stress testing your WebApi.  It integrates very nicely with Fiddler, has a great payment plan (you can purchase for a week/month of testing), and the author provided excellent service. When I found bugs or issues with the product, he had fixes and beta builds ready for me within an hour of reporting them.  It really helped us find our bottlenecks.

Feb 5, 2012 at 3:12 PM

Thanks but I am currently using the one I found in the contrib project and it works very well.
My concerns is regarding wide adoption. Most of the people do not spend much time in digging a technology in order to get the best from it.

I see quite often people making a couple of tests, and declare 'dead' the technology for their use. In some cases performance will be part of this hurried decision. Frankly speaking I can't say that built-in performances are good enough for real-life scenarios.

Thanks again for the pointers.

Feb 6, 2012 at 2:29 PM
dgdev wrote:

We were using Fiddler quite a bit throughout our research phase and in early development.  Here is our JsonNET formatter/extensions.

http://pastebin.com/affN0RxR

Also, check out StressStimulus for performance/stress testing your WebApi.  It integrates very nicely with Fiddler, has a great payment plan (you can purchase for a week/month of testing), and the author provided excellent service. When I found bugs or issues with the product, he had fixes and beta builds ready for me within an hour of reporting them.  It really helped us find our bottlenecks.

Thanks for the link and tip!  I'll be sure to check those out.