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] <Tom.Fransen@home.nl> wrote in message
news:1122615568.576187.115040@o13g2000cwo.googlegroups.com...
> 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
>