all groups > dotnet remoting > july 2005 >
You're in the

dotnet remoting

group:

Latency of remoting calls to a machine with a high CPU load


Latency of remoting calls to a machine with a high CPU load Tom.Fransen NO[at]SPAM home.nl
7/28/2005 10:39:28 PM
dotnet remoting:
Hi,

I have the following question. We have two machines running Windows
XP/SP2. One of the machines does a call via .NET remoting to the
another machine. We see that if the CPU load on the 'receiving' machine
is very high (near 100%) the calls take very long. To some extend this
makes sense as there is only so much work the CPU can do. However the
remoted object lives in a process that has high priority itself so I
guess the thread(s) handling the remoting call will also have high
priority. So why do we still see latencies of 5 seconds or even more.

Apart from a straight answer :-) it would also help if somebody can
explain how the remoting calls are handled. I am interested in the
threads involved in a .NET remoting call. I found some posts discussing
a threadpool and a maximum number of threads in this pool. Has this
some relation to the problem I described?

Any help is welcome

regards
Tom
Re: Latency of remoting calls to a machine with a high CPU load m.posseth
7/31/2005 9:45:29 PM
Well it seems to me that you give the answer to your own question.........

thread prio will make sure that a worker thread is put in front of threads
with a lower prio, however before the thread receives processor time it
still has to wait untill the thread in front of him is ready
see it as going to disneyland with a prio ticket ,,, you are still standing
in line however more in front .

i also believe that a remoting object that runs on a server with such a high
load is a poor choice as beeing the host server , so something is wrong with
this machine ( it is under powered ) , something is wrong with the software
running on it ( operating system , antivius etc etc ) or something is wrong
with the design of your program .

Remoting is multithreaded by nature if you use single call objects ( the
framework handles everything for you ) , only with singleton objects you
have the responsibility for handling multiple clients

i am currently myself bussy with a project that runs with a singleton
exposed over remoting , however i choose a challenge response system with a
FIFO structure ( First in First Out ) as i feel that this gives the best
results without overhead for the synch stuff etc etc ofcourse this comes
with a price this means that a small call must wait untill a bigger call is
processed however on a single CPU systems this also means that the totall
processing is shorter , as thread synch etc etc is also resource consuming
...... if i would know for sure that my project would run on multiple cpu
systems ( dual core not the lame Intel hyperthreading , but really multiple
processors ) then and then only, i think it is interesting enough to invest
time and monney to implement a processing ticket system in your singleton
object

i do not know in wich language you code ,,, but if you are a VB.Net
programmer ican sure recomend you a fine book "Microsoft .Net Distributed
Applications : Integrating XML web services and .Net Remoting " ISBN
0-7356-1933-6 by Matthew MacDonald it is really a great book ,, and
superieur to all the others i have seen it has only 2 flaws Low level
channels are not discussed , and all examples are in VB.Net

this is only a problem if :
1. you are not a VB programmer
2. You want to implement compression , encryption etc etc etc on channel
levell

The book is a originall Microsoft Press book and verry clear ,,, it tought
me a lot

regards \ Groeten

happy coding :-)

Michel Posseth





[quoted text, click to view]

AddThis Social Bookmark Button