• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 204
  • Last Modified:

Performance issues with object remoting (MS.NET)

We are in the process of developing an enterprise project management system using MS.NET (C#).

The internal structure of the system is based on object remoting, which provides a whole lot of great features, but also seems to carry with it a few intricate problems.

The problem is basically that when we access properties and methods of remoted objects, the bad performance forces us to use "ugly" solutions. Let me illustrate this with an example:

Let's assume that "PersonArray" holds 1000 remoted objects of the class "Person". Executing the following code then takes ages!

  foreach(Person CurrentPerson in PersonArrray)
  {
    CurrentPerson.Age++;
  }

If the corresponding code is executed on the server side, the code takes virually no time at all to execute. We have only found one solution that manages to speed the operation up, at least a bit, and that is to send the array to the server side and execute the loop there.

So, the problem is basically that looping over large collections of remoted objects takes ages.

Does anyone know how we can solve the problem? Any tips where we can find in-depth reading about object remoting?



Best regards
Karl Hagstrom
Bite Solutions AB
Sweden
0
Kalleman
Asked:
Kalleman
1 Solution
 
snoeglerCommented:
Hmm this is a typical task which should be DONE at server side. Imagine a SQL database:

UPDATE customers SET customer_id=customer_id+1

If the DB would act like your example, the client of the SQL Server would fetch all records (completely, like SELECT *), increase the field customer_id by one, and send each record back to the server. Now this would take ages :)

You should modify your design, handle processes like this completely on the server and provide a straight, orthogonal interface.
0
 
KallemanAuthor Commented:
OK. I must say that I agree. Making trillions of calls to the server side, instead of making one bach call IS bad. However, my goal is to use an architecture that doesn't force me to implement trillions of methods on the server side like:

UpdatePhoneNumbersForPersons(...)
ChangeOwnerOfCar(...)
RemoveEmployeesFromCompany(...)
...
...

Being able to handle my objects directly on the client side isolates the client from the server and makes the code structure better. I have been trying (without satisfactory results) to implement a solution with disconnected objects, sort of a "check out" of business objects to talk in source code control terms.
0
 
snoeglerCommented:
I have attended an MS event where the contributor pointed out that exactly what you're experiencing is what he expects to make problems with .NET remoting in "real life" programming.

You must understand that remoting is REALLY expensive and is (from my POV) much too comfortable. Consider what the architects of SQL did: they invented a low-level, orthogonal yet complete and manageable language for handling most tasks directly on the server, almost 20 year ago now.

In your case, i'd suggest an interface based on XML. On client side, you implement a light-weight API to help constructing the XML for server side invokes. Sample:

<server-invoke>
 <target what="customer" refid="82">
  <alter what="phone">
   <destval>(+43)738-03939</destval>
  </alter>
 </target>
</server-invoke>

or, in the case of your age example:
<server-invoke>
 <target what="customers" select="{custom SQL WHERE clause maybe}">
  <alter what="age">
   <destval>age=(age+1)</destval>
  </alter>
 </target>
</server-invoke>

In the latter example, the statement 'age=(age+1)' could be passed directly as an argument to an SQL UPDATE statement. If you manage to construct an API like this, you'll experience a performance about 1E+5 times faster than using remoting for that.
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
hmatchenCommented:
A sneaky possibility is to build a stored procedure dynamically, post it to the server, execute it, then delete it.  This has the advantage of flexibility, but requires that the user's workstation have that level of access to the db server.  Update queries don't have result sets, so there's no debris.
0
 
DanRollinsCommented:
I think you should just code the PersonArray remote object with functions that iterate across all of its Person objects, or a specified subset of them:

    PersonArray.UpdateAll( AGE, +1 );

    PersonArray.Update( AGE, +1, "lastname > 'S'" );

The idea being that the Person object never gets moved across the network.

-- Dan
0
 
KallemanAuthor Commented:
Thanks for the feedbak, even if it means I probably have to completely redesign the data tier of our system. *doh*

0

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now