In response to some complaints from customers regarding network utilitization of our CSLA-based application when deployed using a remote data portal, we've done some network snooping and have determined that even the most trivial of requests to the data portal involves a payload of 3K bytes or so of data that is *uploaded* or sent to the data portal, this does not include the data that is returned.
We have determined that much of this is the DataPortalContext (at least 1500 bytes), but we aren't storing anything in the GlobalContext and have what should be only a few bytes of data in the Client context (two integers and one enum). Eliminating the principal saves "only" 300 bytes, so that isn't the problem.
It may not seem like much for one request, but when we have hundreds (and at least in one case thousands) of active clients on a network with the total request rate exceeding 100 per second, it starts to add up quickly.
We are still on a version CSLA 3.5 with selective enhancements from newer versions backported to it. Was this by any chance addressed in a newer version? I'm considering implementing some sort of custom serialization but did not want to reinvent the wheel. Other suggestions or recommendations also welcome.
In current (4.3 or 4.5) versions of CSLA there are more efficient serialization options available.
In 3.5 your best bet is to utilize compression.
Thanks for the quick reply, Rocky. Actually, it was in implementing compression that we discovered the problem. We have implemented Deflate based compression and find that that binary-serialized data that we are downloading will compress surprisingly well, roughly to 25% of original size on average. However, the uploaded criteria/context payload does not compress well at all, generally not better than 50% of the original size and often more than 60%.
Could you point me to something in 4.2/5 that I might be able to take advantage of? I've ported newer features back into our version in the past when it made sense to do so.
Unfortunately it is a pretty major change that comes at a couple levels.
First, the MobileFormatter was changed to allow the use of custom reader/writer components - the things that actually generate and consume the byte stream.
Second, there's a new and more efficient reader/writer component pair.
Finally, the overall framework was modified so MobileFormatter can be used in pure .NET scenarios, where before it was just Silverlight/WP7. Now it can be used anywhere.
Copyright (c) Marimer LLC