Hello,
We have a win form application that uses CSLA framework and is completely developed by following the ProjectTracker example i.e. the business objects and data access layer are logically separated but are not in separate dll’s. We would have preferred to have a separate dll’s for BO and Data access however we realized that too late in the game and had to deploy the application in production as is.
This application has recursive objects (parent, child, grandchild relationships) and that has made the design fairly complex. It was all fine when we had the database server and clients on a LAN however since the day database server was moved to a distant location over WAN, performance issues have cropped up which had made application unacceptable.
We have made some significant design improvements using lazy loading techniques which has boost up the performance a lot. As a second step we were hoping to use .Net Remoting with an assumption that if the data access layer is near the database server (on LAN instead of WAN) we will find the performance to improve significantly.
The application has a windows form client project (XYZWin vb.net project) and a business assembly (XYZ.Library vb.net assembly) that includes the data access layer which is logically separated. We have followed the steps mentioned in Rocky’s book for the .Net remoting set up on client and server side. The server side set up is done correctly as we are able to verify the set up with ‘?wsdl’ as mentioned in this post http://forums.lhotka.net/forums/thread/3244.aspx.
To our surprise, after the setup we ran some tests and always found that with .Net remoting turned on the performance degrades as compared to client going directly to the database over the WAN!! In this scenario we have following questions with regard to client side configuration and performance -
1> Business Assembly: We have to reference the business assembly on both the app server and the clients, why do we need to have a reference to it on the clients? When we were stepping through the code in debug mode we found that we were able to step through the business library till we hit the factory method the dataportal_XXX were executed on the server.
2> App.Config: Why do we need connection string information in app.config on client side? Ideally we should only have database connectivity information in the web.config on the app server right? We may not have this set up correctly so let us know if we really need the connection string information in app.config or not.
3> Performance: Provided we did set up .Net remoting as was expected (i.e. client side and server side) Why did we see performance to go down with remoting turned on? Is there some overhead with remoting that is causing the numbers to go high as compared to clients going directly to the database over the WAN?
This is my first post on this forum and I really hope to get some help from your experience. Any help will be much appreciated ![Smile [:)]](/emoticons/emotion-1.gif)
Thanks,
Mugdha
mugz:
1> Business Assembly: We have to reference the business assembly on both the app server and the clients, why do we need to have a reference to it on the clients? When we were stepping through the code in debug mode we found that we were able to step through the business library till we hit the factory method the dataportal_XXX were executed on the server.
2> App.Config: Why do we need connection string information in app.config on client side? Ideally we should only have database connectivity information in the web.config on the app server right? We may not have this set up correctly so let us know if we really need the connection string information in app.config or not.
You don't. If you take the connection string out of your App.Config, and your application bombs because it can't get to the database, you screwed up your model. You have data access code running on the client directly accessing the database server. I only have the database connection string in the Web.config on the application server.
3> Performance: Provided we did set up .Net remoting as was expected (i.e. client side and server side) Why did we see performance to go down with remoting turned on? Is there some overhead with remoting that is causing the numbers to go high as compared to clients going directly to the database over the WAN?
Given your #2 statement, it's possible you've got data access code running on the client. Also, you may have to mark some private fields as NonSerializable, because if you have references say from a child to the parent, the parent field serialization in the child will add to the byte stream. Also, you may want to check the forum for a link to the CompressedRemotedDataPortal, which compresses the byte stream.
Switching to remoting + compression greatly improved application speed for my users in our other office. But it still won't be as fast as having the server on the LAN. Given that, I'd argue that the server should be physically located on the lan with the most heavy use users.
At the same time, which I first tested an actual remoting configuration, I found I had a bunch of places were I wasn't keeping all my data access limited DataPortal_XYZ methods... even though I thought I had been.
I'd start by taking the connection string out of the App.Config and testing my application in a remoting configuration.
Also... if possible use WCF... it has built in support for compression. Unfortantly I've not had time to look into that myself.
HTH
Andy
Thanks a lot Andy.
Yes, when we try to remove the connection string from app.config the app blows up so first thing to try is to figure out the dependency and fix that. Once that is fixed we will look into the CompressedRemotedDataPortal. Do we need a later version of CSLA for that? Currently we are using CSLA 3.0.4.
Copyright (c) Marimer LLC