 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / Distributed Applications / September 2005Short .net remoting calls and bad performance
hi all, in my distributed application i have the problem that i send many short .net remoting calls which are leading to a bad performance. i already use remoting over tcp and the binary formater. so, is there a way for example to send client-requests/calls delayed to the remoting server? the client request/call to server will be only send after a 200ms idle, so all the client requests would be stacked into ONE big request and beeing send at once after 200ms idle. or are there any other solutions for that? the reason for the bad performance is the lazy-loading pattern in my architecture. for example: two tables/entities, one is person, the other one is address.. the entity person has a address property. the address is lazy loaded, so if i want an overview over all users and theire addresses, a lot of lazy loading is happen and so far many short remoting calls are executed. thanks, steven. Hi Steven! > in my distributed application i have the problem that i send many short > .net remoting calls which are leading to a bad performance. i already [quoted text clipped - 5 lines] > into ONE big request and beeing send at once after 200ms idle. or are > there any other solutions for that? There is no built-in solution for that. You may have a look at http://www.genuinechannels.com/, but I don't know if that commercial product provides what you need. > the reason for the bad performance is the lazy-loading pattern in my > architecture. for example: two tables/entities, one is person, the > other one is address.. the entity person has a address property. the > address is lazy loaded, so if i want an overview over all users and > theire addresses, a lot of lazy loading is happen and so far many short > remoting calls are executed. You should consider making your interface less chatty. For example by providing methods that fetch all necessary data at once, something like GetPersonWithAddress in your case. Rob Hi Rob, thank you for the url. >> You should consider making your interface less chatty. >> For example by providing methods that fetch all necessary >> data at once, something like GetPersonWithAddress in your case. well, currently i benefit from my current interface, because now i dont have to pay any attention about using GetPersons() or GetPersonsWithAddresses()... the user interface itself is just getting what it's needing and populating it on a simple way.. like: persons = session.FindAll(); foreach person in persons ) { row.Add( person.name ); row.Add( person.address.city ); row.Add( person.address.country ); } steven. and by the way: the problem is not the lazy loading, its more a "getting an object from an object". no matter if've loaded the address already or not, whenever i want to access a child entity of an parent entity, it's a remoting call again. looking at one person and its address its not a big deal, but it is a performance lack to look at an overview of 1000 records. steven. > the problem is not the lazy loading, its more a "getting an object from > an object". no matter if've loaded the address already or not, whenever > i want to access a child entity of an parent entity, it's a remoting > call again. looking at one person and its address its not a big deal, > but it is a performance lack to look at an overview of 1000 records. Well, you cannot expect in-process speed from remoting. That's why I said use a less chatty interface. If you're using MarshalByRefObjects with a lot of properties, then you *have* a chatty interface. Try using serializable objects which transfer more data at a time. (Typed) DataSets for example. Rob right you are :-( yes, i'm using MarshalByRefObjects with many properties.. now i understand what you've mean with *chatty* interface ;-) ..sadly i can't switch to datasets due the architecture/framework we are using here. ..so thats why i thought about delayed/stacked calls, for sending everything the caller needs at once instead seperated. steven.. Hi Steven, > right you are :-( > yes, i'm using MarshalByRefObjects with many properties.. now i > understand what you've mean with *chatty* interface ;-) ..sadly i can't > switch to datasets due the architecture/framework we are using here. > ..so thats why i thought about delayed/stacked calls, for sending > everything the caller needs at once instead seperated. Look at this sample (o is a remoted MBO): int i1 = o.Property1; int i2 = o.Property2; If the call "o.Property1" gets delayed, the next call "o.Property2" doesn't get executed because the calling thread must be suspended while waiting for o.Property1 to return. If the call "o.Property1" would return immediately, because the call were queued, which value should "i1" be assigned with in the meanwhile? And how should "i1" be updated when the call returns? It's impossible. You should consider replacing your properties with something like that: GetProperties(ref int prop1, ref string prop2, ...) Ugly but efficient. Rob > Look at this sample (o is a remoted MBO): > [quoted text clipped - 11 lines] > should "i1" be updated when the call returns? > It's impossible. exactly what i've found out while you posted it here. damn! i become aware that we are object-oriented and not service-oriented here.. and thats pretty bad, because so many things are already implemented and it would be a pain for everybody here to give up our *lovley* architecture.. just for making the application(s) fast with .net's remoting. i ask my self how all the other people who are working with frameworks like nhibernate are solving that *chatty* stuff? anyway.... thank you for help robert ! Steven - you need to be chunky across processes and you "can" be chatty within a process. so whenever you're communication "across the wire" you have to pass something else. ice > > Look at this sample (o is a remoted MBO): > > [quoted text clipped - 21 lines] > > anyway.... thank you for help robert ! You don't have to give up the "lovely" architecture; you can still use in for in-process message passing between objects, but use the Facade design pattern to create additional classes which provide the "chunky" interface as Rob proposed. Use the "chunky" interface for remoting call, now you can have the best of both worlds. HTH, Alex Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.