Legal Information
PC Knowledge Base - How to Test Microsoft Remote Procedure Call Performance
Good Knowledge Is Good2Use

The following describes how to test Microsoft Remote Procedure Call (RPC) performance, and how to troubleshoot RPC error messages.
RPC is compatible with the Open Software Foundation (OSF) design and interoperable with other Data Communications Exchange (DCE) standards. RPCs are industry standard Interprocess Communication (IPC) mechanisms for client-server communications that are network independent and can work over a variety of network protocols. RPC uses IPC mechanisms to establish communications between the client and server to call program functions on a remote computer.

The complex programs that use this level of service require that there be a connection, or level of throughput, to adequately deliver this functionality. For example, when you are using Microsoft Exchange Server, a connection is needed to reliably maintain the flow of data.

RPC Error Messages

When you use RPC, you may receive any of the following error messages, which may or may not be caused by slow network connectivity:

Troubleshooting RPC Performance and Error Messages

There are many tools you can use to determine if an RPC error message is being caused by a slow network connection. If you receive an RPC error message, eliminate slow network connectivity as the possible cause. Use one or more of the following methods to isolate the problem.
To resolve the problem of name resolution as a cause of the RPC error message, verify that you can use the NET VIEW command at a command prompt on the destination server. If Transmission Control Protocol/Internet Protocol (TCP/IP) is the protocol used between the client and server programs, you can use an Lmhosts file to eliminate Windows Internet Naming Service (WINS) as a possible contributor to the problem.

You can test basic RPC connectivity by using another RPC program. Windows NT Server includes several RPC programs. Event Viewer (Eventvwr.exe) and Registry Editor (Regedt32.exe) can have their focus set to any computer running Windows NT. Other programs such as User Manager (Usrmgr.exe) and Server Manager (Srvmgr.exe) set their focus on the Primary Domain Controller (PDC) by default. Use one of these programs as another test for RPC connectivity.

To test network connectivity, monitor the speed of a basic file copy across the network using Performance Monitor (Perfmon.exe). To give the test an adequate sampling time and to fully allow for segmenting and sequencing, only test with a file that is at least 2 megabytes (MB) in size.
To copy a file across the network using Performance Monitor:

  1. Locate a 2 MB or larger file. If you do not have a 2 MB file readily available, you can use the COPY command to create the file from an existing file. To do so, type the following command at a command prompt, and then press ENTER:
    copy /b file.ext + file.ext + file.ext + file.ext destination.ext
    NOTE: Use the binary (/b) switch when the source file is not text. This prevents CTRL+Z being read as an end-of-file character.
  2. Start Performance Monitor on the client computer. Since Performance Monitor cannot distinguish between connections to different computers for a file copy, you may want to disconnect all current network connections if other connections may influence the results. To disconnect all current network connections, type
    net use * /d
    at a command prompt, and then press ENTER.
  3. Performance Monitor can monitor a file copy for the server or redirector object using the Bytes Transmitted/sec, Bytes Received/sec and Bytes Total/sec counters. To simplify the procedure, and to more accurately represent the flow of data in the RPC connection, copy a file from the server computer to the client computer that is running the RPC program. A 2-MB file needs to be located on the server computer.
  4. In Performance Monitor on the client computer, follow these steps:
    1. On the Edit menu, click Add To Chart.
    2. In the Object box, click Redirector.
    3. In the Counter box, click Bytes Received/sec, and then click Add.
  5. .At a command prompt, map a network drive letter to the server computer and then copy the file from the server computer to the client computer.
  6. In Performance Monitor, observe the average, maximum, and minimum values. If you are testing with a 128-Kbps link, observe the average counter to verify that the copy process is running close to 75 percent of the 16,384 bytes per second theoretical limit (.75 x 16,384 = 12,288 bytes per second).
    This value should be higher for important functionality and may indicate the need for network expansion. As a gauge, measurements that approach 800,000 bytes per second (bps) are excellent. The following table lists conversions for kilobits per second (kpbs) and Kilobytes per second (KBps):
    Connection speedBytes per second (bps)
    128kbps16,384
    512kbps65,536
    1.544Mbps (T1)193,000
    10Mbps (Ethernet)1,250,000
    46.320Mbps (T3)5,790,000
    With a certain line speed, such as 128K, you see less than the full 16,384 bps throughput based on utilisation and other factors. These numbers are a theoretical maximum, and network overhead reduces them.
  7. To further eliminate general network connectivity as the problem:
    1. In Performance Manager on the client computer, click Add To Chart on the Edit menu.
    2. In the Object box, click Redirector.
    3. In the Counter box, click Bytes Transmitted/sec, and then click Add.
    4. Copy the file back to the server computer, and monitor the rate at which the file is copied.
NOTE: Be certain that these tests between the client computer and server computer are acceptable for the level of service desired. To perform additional tests using Performance Monitor, by reverse the direction of data flow between the client and server computer, select the appropriate counters.

Another way to test RPC communication between two computers is to use the Rpcping tool.

Other causes of RPC error messages may be third-party services or larger services running on the client or server computer. To determine if running services are causing the problem, stop all non-default services and test RPC performance using Event Viewer and Performance Monitor again.
Check the state of the RPC services on the client and server computer. To do so, type net start at a command prompt, and then press ENTER. For a domain controller, the following information is displayed:

To further check the state of these services, use the Sc.exe tool included with the Microsoft Windows NT Resource Kit.For additional information about using the Sc.exe tool, click the article number below to view the article in the Microsoft Knowledge Base: 166819 (http://support.microsoft.com/kb/166819/EN-US/) Using Sc.exe and Netsvc.exe to Control Services Remotely

Services.exe contains much of the RPC code, and one of its threads may be in a hung state. Use the Dr. Watson tool (Drwtsn32.exe) to determine if an error message has been reported. Even if no error message has been reported, one of its threads may be hung. If this is the case, you may need to restart your computer. You can use the Tlist.exe tool included with the Windows NT Resource Kit to obtain information similar to the following: 62 Win32StartAddr:0x022a3ca1 LastErr:0x000003e5 State:Waiting 64 Win32StartAddr:0x022a4895 LastErr:0x00000000 State:Waiting 67 Win32StartAddr:0x76e03f90 LastErr:0x00000000 State:Waiting 4.0.1381.4 shp 0x02290000 services.exe 4.0.1381.4 shp 0x77f60000 ntdll.dll 4.0.1381.4 shp 0x77e10000 RPCRT4.dll Examination of the state, files, and dates may provide additional information.

You can use the Pmon.exe tool (included with the Windows NT Resource Kit) Task Manager to obtain information about Services.exe, such as memory and CPU consumption. The Pstat.exe tool, included with the Windows NT Resource Kit, displays thread states for Services.exe. The information in this article applies to



Search Knowledge Base Feedback
If you like our web site refer a friend.
Your friends name.
 Your friends email address.
Your Name
 Your Email Address


© Copyright 1998-1999 GOOD2USE