Sorry to poke in

Ur component as u say is an exteremly good candidate
for COm+ deployemnt - multithreaded and all - So why
not let the clients simply create an instance and call it using
normal DCOm instantiations - why hand over a callback
interface ? And to all the gurus here how differnlty does
RPC behave with a callback interface compared to the
normal route ?

And then again it is really great using OLE DB and all that
but would be of no use if you are blocking the database
inserts in some way or another like using the default
serialized transaction level at the MTS end - if infact it is a
bottleneck maybe u should be trying to optimize more of
that side which would keep returning the RPC threads
back to the pool and keep the context switches to a minimum

arun

ps: out of interst what kindof a situation gives the clients
a chance to create so many threads and the equivalent
load at the server ?

----- Original Message -----
From: "Max Surace" <maxsuraceALTAVISTA.COM>
To: <DCOMDISCUSS.MICROSOFT.COM>
Sent: Wednesday, February 13, 2002 5:14 AM
Subject: Re: RPC/DCOM Server scalability

> my replies inline:
>
> > [Brian Muth] Joe is correct in pointing out that if you are creating
> > hundreds of threads, you are likely causing trouble on the client
> > itself. The time spent context-switching is likely going through the
> > roof. This is not a good design.
>
> [Max] i guess i was talking about frequency and #concurrent RPC calls.
Creating 600 threads does not cause a strong machine to gasp for breath,
especially if most of the operations in the scripts r blocking. But making
600 RPC to a server from a number of client machines would certainly
strangulate the server especially if the server processing is taking a bit
long time. Even if i create a 10 therads per machine, but increase #client
machines to 60, how does it make thois situation any different from 600
therads per machine, for the server?
>
>
> > [Brian Muth] Kinda defeats the purposes of creating hundreds of threads,
> > doesn't it? This doesn't make sense to me why you are doing this.
>
> [Max] Threads r created to execute scripts. if %CPU is like 90 with 600
threads running, y does it not make sense to u?
>
>
> > [Brian Muth] I doubt very much you have stumbled on a hitherto unknown
> > RPC bug that needs a custom workaround, when likely this is a
> > fundamental design problem. I think you are trying to paint over the
> > rust here. Unfortunately, unless you can provide more detailed
> > information about what this project is trying to do, it is difficult to
> > suggest design options.
>
> [Max] I need valued opinions on this 'fundamental design problem', that
is y i am posting here. If any more info is needed, i can provide too.
>
>
>
> Find the best deals on the web at AltaVista Shopping!
> http://www.shopping.altavista.com
>
> ----------------------------------------------------------------
> Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
> contains important info. Save time, search the archives at
> http://discuss.microsoft.com/archives/index.html .
> To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]