Vibrant discussion about CSLA .NET and using the framework to build great business applications.
I've been scanning through the forums reading post regarding Wcf compression and all that I seem to find is compression related to Silverlight.
Has anyone successfully implemented Wcf compression in a non-Silverlight application? We are currently using remoting with compression and I would like to compare performance making the switch to Wcf.We are unable to move away from 3.0.4 at this time so I can't use any of the newer versions of the framework.Thanks,John
Early on we used the Microsoft sample.
To squeeze more performance out of WCF working with large CSLA objects we moved to Noemax's FastInfoset and Compression products. We've been using it for more than 5 years.
Nice thing with .NET/WCF you don't need to do anything special with CSLA. It can be setup in config files. It is transparent to CSLA.
Paul, your e-mail really interested me... it looks like a sitewide license is $3K+ but they suggest the compression is much better which really would seem to translate directly to a better CSLA Silverlight experience.
Any issues with using this library? What sort of compression setting do you use with this? I'm half inclined to test the various settings in terms of compression speed & compression %. Had you done any benchmarking between the free-type libraries and this one with CSLA BOs?
It's always been on my list to see if there were better libraries out there... your e-mail made me think about more seriously exploring it.
Thanks in advance
No major issues to speak of. Mostly drop in and go. Well, this is WCF so you'll probably fight with your config files for a bit but Noemax does have an online config generator which makes it easier.
About a year ago I went back and tried our application with different bindings. I tried a couple of Noemax FastInfoset bindings using different compression techniques. I also fell back to one of our old custom compressed binary binding and a few out of the box ones from Microsoft (HttpBinding Text and Binary). I don't have the results anymore but with real world usage with our application I decided on Noemax FastInfoset with DeflateGZip compression. Our application is all over the place with object graphs. We have simple ones and complex timecards that go several levels deep. A moderately complex timecard object can be several 10s of megabytes across the wire.
One free-type library crossed my radar a few months ago that I am probably going to try after the new year. Not sure though if it works correctly with WCF/CSLA.
Thanks for the information, Paul. I will check out each and see how well it works for our project. Without getting into the details just yet, it appears that the Noemax solution seems the easiest to implement without having to change code.
So I've downloaded the trial for Noemax and have been fighting with it to work with my test project. You said you were able to configure it to work without having to make any code modifications?
fwiw I was able to get it working & with the configuration I was using I had compressed objects that were 2% bigger but the compression time was 40% faster. Nothing super scientific, I just added a couple variables in my compression utility class and totaled up bytes & timespans for each object compression. Went around my application and did some general common use cases. Didn't test decompression.
The thing I was interested in most was a smaller compressed object, that's more valuable to be because my server isn't a bottleneck and compression/decompression itself is pretty quick... if I noticed a 20% better compression size, that'd have been meaningful to me. I'm not expert in compression and I didn't spend additional time so perhaps there's a configuration that gives me better results.
If I remember right there was discussion about a serializer that wouldn't have the serialization of business objects be so big in the first place... if I remember right that's something that was actively being considered for a future version of CSLA but I'm probably not remembering that correctly.
I wondered if that second Noemax product mentioned above actually addressed the verbosity of the XML...
Anyway just wanted to mention the very unofficial benchmarks that I had gotten. Your mileage may vary.
Sorry for the late reply. You should be able to use Noemax without any code changes as long as all your WCF configuration is in the .config files.
Serialization with FastInfoset is considerably smaller than POX (plain ol' XML) and .NET binary.
Thanks Paul. I was able to get it working but I will need to check a few more details out because I am not seeing the compression when using Fiddler. When I go back to my remoting configuration, I can cleary see the compressing that is taking place, but with the Wcf configuration, I don't see it just yet.I will spend more time tomorrow on this and see what I can find. I'm starting to wonder if because I am compressing the remoting objects in code using ISharpLib is the reason for what I see in Fiddler. Using Wcf, fiddler does report the request as compressed but the size of the object indicates that there is no compression or very little taking place.Thanks again for the feedback.John
Paul,I just thought I would share my results with Noemax. I wired up many different configurations and I was really unable to find that it outperformed my current SharpZipLib compression with remoting. Some of the times were slightly faster but the compression was not better.The best results I got were with the configuration you mentioned - Fast Infoset and GZipLib. I plan to spend a little more time to see if I can get some better performance but as it stands now, I may be better off using SharpZipLib and sub-classing the Csla Wcf classes.Regards,John
Thanks for the follow up. I think it all boils down to what is best for your environment. I am glad you took the time to discover your own results then blindly relying on someone else's word and complaining later that nothing is different :)