Server object - init takes about 50 seconds

[2bean]

Hi,

I have a client and server component communicating through DCOM using callbacks. (No MTS pure DCOM VC++6)

The client component sits on Windows 95/98 and uses DCom for Win 95 (1.3). The server component sits on a Windows NT 4.0 Workstation SP 5.0.

On initially calling the server it takes about 51 seconds to initialise the server object, before proceeding to execute the functionality of the function called.

The next time the client calls the server the response drops to about 2 seconds.

Also after about 5-10 minutes the connection has been dropped and again the client has to wait 51 seconds for a response.

Has anyone had the same problems and/or can suggest a solution?

The server is an service and is multithreaded. I have tried different permissions and Dcom configurations on both client and server.

When the NT client is in the same NT - domain and local lan
the initialisation is less than 3 seconds.

Regards
Uwe

 

[chiph]

How is the DNS configuration on your network? Got a WINS server? Because it sounds like it might be doing a name resolution.

Chip H.

 

[cutevindi]

Hi
about me..am a small time programmer and partly into quality. Now we have this Dcom Server running on a NT Server..and it is built entirely on Delphi, using Midas(dont ask y). We have had this problem of hanging of the software and no response coming from Server to the client incase of huge volume of data entry. Was thinking if you could think of something and throw some light on it.

cutevindi

 

[gschmeus]

We have a similar problem with an Exe-Server under COM+ which is invoked by an Active Server Page running in Internet Information Server. If the system was idle for some time the first invocation fails with a timeout. Subsequent invocations succeed.

As a workaround I configured the Exe-Server as "Keep running when idle" in COM+. If your COM component supports object pooling you can also set the minimum pool size to a value greater than 0. Since this configuration the problem did not occur anymore here.

 

[Guest_imported]

io

 

[hoterpone]

I have experienced the same problem where my DCOM (OPC) client sporadically disconnects every 6 minutes. Up until that point everything seems normal, but then all communications stops. Have you found the cause of this problem in your application?

 

[programsecrets]

There are a couple of issues with DCOM...

- there's the overhead of marshalling data from the client to the server side.

- there's the issue of instantiating an instance of a COM server object each time a call is made.

- there's the potential issue of heavy network traffic slowing everything down.

- there's a potential issue of protocol misconfiguration, such as having a number of unnecessary protocols installed. Then, each time a call is made, each protocol must be tried until finally the right one is found.

- After a call is successfully made, the data again has to be marshalled back to the client.


Any (or a combination) of these issues could be causing long delays or even time-outs. What can be done?

- Minimize the number of separate calls being made. Try to send everything in one call, rather than in several smaller ones.

- Minimize the amount of data that is being passed or returned, if possible (especially if it isn't being used anyway). Instead of "select * from TABLE", select only the columns needed, and filter the number of rows to what is actually required by the application.

- Use object "pooling" for frequently used server objects. That way, they will exist and won't require instantiation and initialization each time a call is made. Use a time-out value to destroy them if no call has been made after a set amount of time.

- Remove any unused network protocols. Then, make the most likely protocol to be used the "default" (or first in the list).

- Minimize the amount of marshalling that must be done. Keep interdependent COM objects on the same machine, or even in the same process.

Those are just a few suggestions... I know a couple are similar to ones that were mentioned by others above.

I hope this helps, or at least gives you some ideas.