dotnet distributed apps: low COM call performance in second thread + remoting = no logical workaround ?? -- dotnet distributed apps

low COM call performance in second thread + remoting = no logical workaround ??

zavairax NO[at]SPAM yahoo.com
10/27/2003 3:07:46 AM

dotnet distributed apps:

Hi Everyone!
This is a problem which makes mind goes in circles:
The application needs to run a remote procedure on other machine which
in turn needs to make some millions of COM calls to store a data from
DB to the memory.
Millions of COM calls works about 50000/sec when done from the main
thread e.g. console app.
But when the client calls a function through the remoting the
performance of COM calls degrade about 20 times. I could not find an
explanation for this (the application and the COM is STA) maybe this
is the way it should be - does anyone know BTW?
The problem is to make a workaround for this - to run COM calls in the
main thread and to reference this COM object populated with data from
the function ran through remoting.
One need to make a DLL type library to pass the interface information
with this DLL to the client - so on the server when the function ran
through remoting starts is has NO reference to the thread or class
which started it - am i right ?
Is it possible at all to pass a reference of an object created in a
main thread to the function ran through remoting ?

Re: low COM call performance in second thread + remoting = no logical workaround ??

zavairax NO[at]SPAM yahoo.com
10/27/2003 2:42:09 PM

The "first-post-then-check" method helped,
once a new ATL object was created with "Both" single and free theaded
models attribute as was widely suggested, the performance of COM calls
from child thread increased to the necessary speed. DotNet remoting
rocks.

[quoted text, click to view]

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages in the dotnet distributed apps group.