I am currently using CSLA 3.6 and am willing to upgrade to 3.8 to obtain any efficiencies.
WinForms VS2008 .NET3.5, CSLA 3.6.X, WCFproxy
I have been building some CSLA objects and started testing them. I received an error where I needed to increase the maxReceivedMessageSize. However, the object wasn’t that large, it had several (~600) small child objects. I quickly came up with an estimate of what size I thought the object should have been and it (the estimate) was lots smaller. So I used Fiddler2 to look at the packets. Was I shocked at the amount of overhead the XML had added, probably around 10x what the raw data would have been. After some initial research it looks like CSLA WCF is using the NetDataContractSerializer.
So after some research here I found several optimizations mentioned:
1. Compression CSLA
2. Compression WCF
3. BinaryFormatter (WcfBfProxyHost) vs NetDataContractSerializer.
4. BinaryXML (Mobil only?)
The problem is that I am having difficulty understanding
1. which methods to use (in combination with each other).
2. Which techniques are the most current (have some been replaced with new better techniques)
3. Are some techniques only for Mobile/SL .
4. How to implement them.
I know this is asking a lot but can someone outline what the current recommended techniques are and point me in the direction of some info on how to implement them.
The .NET serializer (NDCS) does generate some massive amounts of XML, no doubt about it.
The good news is that much of the bulk is in the form of repeated xmlns, assembly and type strings. The reason this is good news is that compression is extremely effective because the repeated strings are eliminated, plus other compression occurs as well of course.
The only place you can easily plug compression into the data portal is with the Silverlight data portal. I didn't bother to add those hooks in the .NET side, because you can just go get a compressed WCF binding instead.
(I rather suspect there are, or will be, compressed WCF bindings for Silverlight too - but they didn't exist when we added the compression hooks to the Silverlight data portal, so some immediate answer was required)
RockfordLhotka:
[...] I didn't bother to add those hooks in the .NET side, because you can just go get a compressed WCF binding instead. [...]
[...] Let me know if you are interested.
Update: I set up the Csla.Server.Hosts.IWcfBfPortal (BinaryFormatter) and got some good performance increases.
For the same Same Object (data) I am getting the following increases using Fiddler to track the http request from the client:
NetDataContractSerializer
Request Count: 1
Bytes Sent: 8,716
Bytes Received: 7,213,938
ACTUAL PERFORMANCE
Overall Elapsed: 00:00:04.4218467
IWcfBfPortal (Bindary Formatter)
Request Count: 1
Bytes Sent: 7,284
Bytes Received: 918,732
ACTUAL PERFORMANCE
Overall Elapsed: 00:00:02.2031109
So, the next question is about the compression that has been mentioned. Will I really get much more of an improvement with compression. As I understand compression doesn’t work well (as well) with binary data.
Or would I be better off not using a Binary Formatter in WCF and using compression (only) in WCF?
While that’s true, I suspect you’ll get even better perf
increases if you use a compressed binding with NDCS.
I created WcfBfProxyHost as an experiment, in response to
someone else pointing out the size of the XML created by NDCS. In their testing
(so just one real data point) it was faster to use WcfProxy with a compressed
binding.
Using WcfBfProxy with compressed binding is almost
counter-productive btw. This is because the binary data generated by the
BinaryFormatter doesn’t compress well – as is true of most binary data.
If you want to get the best performance, take a look at the emerging Efficient XML Interchange (EXI) standard from the World Wide Web Consortium (W3C). It is far more compact than .NET Binary, FastInfoset, BinaryXML (WBXML), compression, etc. and does not incur the processing overhead of compression. The W3C conducted extensive benchmarking of different candidate technologies for the EXI standard and found there was one technology (called "Efficient XML") that consistently achieved the best performance across all their test data, use cases and application classes (see full report). The W3C adopted "Efficient XML" as the basis for the single, global standard for the WWW. FastInfoset was also one the candidates considered; however, it did not achive sufficient compactness or generality to meet the requirements (see requirements matrix).
I work for the small company that developed Efficient XML. We were co-founded by an ex-Microsoft XML veteran and offer a plug-in for Microsoft WCF as well as standard APIs for .NET and .NET CF apps. The plug-in has built-in compression, supports dynamic content-negotiation and interoperates with versions for Java, Java Mobile Edition and native C/C++. If you want to try it out, you can download a trial version of the SDK from here.
Enjoy!,
John
John,
Is it affordable for a SMB / small app / small user base or is
this more geared as an enterprise type implementation?
From: JohnSchneider [mailto:cslanet@lhotka.net]
Sent: September-25-09 11:00 AM
To: jaddington@alexandergracie.com
Subject: Re: [CSLA .NET] RE: Compression? BinaryFormatter? What are the
current techniques?
If you want to get the best performance, take a look at the emerging
Efficient XML Interchange (EXI) standard from the World Wide Web Consortium
(W3C). It is far more compact than .NET Binary, FastInfoset, BinaryXML (WBXML),
compression, etc. and does not incur the processing overhead of
compression. The W3C conducted extensive benchmarking of different candidate
technologies for the EXI standard and found there was one technology
(called "Efficient
XML") that consistently achieved the best performance across all their
test data, use cases and application classes (see full report). The W3C adopted
"Efficient XML" as the basis for the single, global standard for the
WWW. FastInfoset was also one the candidates considered; however, it did not
achive sufficient compactness or generality to meet the requirements (see requirements
matrix).
I work for the small company that developed Efficient XML. We were
co-founded by an ex-Microsoft XML veteran and offer a plug-in for Microsoft WCF
as well as standard APIs for .NET and .NET CF apps. The plug-in has
built-in compression, supports dynamic content-negotiation
and interoperates with versions for Java, Java Mobile Edition and
native C/C++. If you want to try it out, you can download a trial version
of the SDK from here.
Enjoy!,
John
Both. There are per-copy licenses for smaller deployments, per-application licenses for medium-to-large deployments and unlimited enterprise licenses for very large deployments involving many applications. To find out what might work best for you, I recomended shooting a quick e-mail to sales@agiledelta.com.
All the best!,
John
Copyright (c) Marimer LLC