WPF / WCF & Compression :(

WPF / WCF & Compression :(

Old forum URL: forums.lhotka.net/forums/t/8049.aspx


peteisace posted on Thursday, November 26, 2009

hi, i'm sure i'm being quite stupid, but i would love some (detailed if possible) help with sorting out some compression for the WCF dataportal.

first - the app is a WPF windows app, using a WCF dataportal for the dataaccess. however, once the WCF service has been moved to the real server, the performance is horrid.

as such, i'd like to experiement with compression on the WCF service. but i don't know how...

all the examples i've seen are for the silverlight projects. my knowledge of WCF is actually nothing, and i get the impression it can be a bit of a config hell hole.

i don't think i can modify / inherit a CSLA portal / proxy class because it's a standard WCFPortal, not the Silverlight one. Is that correct?

i've been looking at the WCF extensions project on Codeplex, but as of yet have been unable to configure it. has anybody tried using this with the CSLA WcfPortal?

what should be the approach here - try and inject something as a before / after on the WCF side (some new custom binding, or binding extension or something), or try and modify a CSLA class? i'm NOT and will not be using the Silverlight portal, just the standard WcfPortal. i don't believe this has compression out of the box?

i'm not using 3.8 as of yet, so there's no binary xml or anything. frankly i'm looking for some bog standard gzip compression and see if that improves things.

like i said, i know practically nothing about Wcf, and i'm not overly au fait with the CSLA dataportal implementation.

Any pointers, guidelines, anything in fact would be extremely welcome. i fear a week of pooring over a config file are about to happen...

Help me, Obi-Wan Kenobi; you're my only hope

RockfordLhotka replied on Thursday, November 26, 2009

I love the Star Wars reference :)

The .NET WCF data portal channel is "closer to the metal" than the Silverlight version. In other words, .NET and WCF do essentially all the work, where in the SL case CSLA has to do more work because the built-in functionality just doesn't exist.

The advantage of the SL approach is that we were able to provide clear places to inject compression. The drawback of the SL approach is that there's more overhead in general. I would prefer if Microsoft implemented a NetDataContractSerializer in SL so we could just switch back to the .NET model...

The advantage of the .NET approach (what you are using) is that there's less overhead in general. The drawback is that .NET is doing all the work, so we can't inject steps into the process. Unless we incur the same overhead as on SL, we can't provide comparable compression options.

However, you can just purchase third-party WCF channels that do compression, and that's what I recommend. Why mess around with this at all, just buy a compressed channel and be done with it.

You might also be able to find ways to do compression in WCF yourself. WCF is incredibly extensible, and the data portal is just using standard WCF functionality. So any technique people use to compress WCF messages will almost certainly work with the data portal as well as any other WCF scenario.

In other words, on the .NET side CSLA gives all responsibiilty to WCF, which is good, because it means you can just use standard WCF techniques to get compression - totally independent of CSLA.

DocJames replied on Thursday, November 26, 2009


Hi,

My application is a ClickOnce Windows Forms application, with a WCF Data portal on the server.

I'm using the WCF-Xtensions from Noemax for compression. It works out-of-the-box with the Data portal.

Let me know if you want to see the config files I'm using.

Thanks,
Jimmy

peteisace replied on Thursday, November 26, 2009

hi, thanks for the replies.

i got it working using the codeplex stuff in the end, which provides acceptable compression (compressed message was about 18% of the original size on the test that i did).

it turns out that it's not that difficult to integrate - and it's open source, so i can change the compression behaviour / algorithm if necessary.

i'm happy to post what i did, the servicemodel entries in the config files that i used (client & server) to get this running, if it would be of any use to anybody; i think there's a few posts around this area. happy to accept though, that the way i've done it might not be optimal.

finally starting to see the point in WCF too :)





shawndewet replied on Friday, November 27, 2009

Please do post your ServiceModel config sections for the client and server...I'm also starting to figure out the WCF Dataportal and I'd love to see what you've done.

Also, would you please let me know what tool you used to measure that the compressed data was 18% of the uncompressed data?

JohnB replied on Friday, October 28, 2011

Peteisace,

I know the post is old but I'm curious if you're still using WCF an compression? I spoken to others on the forum about this and I would like to know what you ended up using as a final solution.

Regards,
John 

Copyright (c) Marimer LLC