RPC over HTTP Scalability

RPC over HTTP places a light load on the RPC proxy server and should not adversely affect its performance.

To validate the load that is generated, you can use Exchange Load Simulator (LoadSim) 2003 to simulate clients that connect over RPC over HTTP. For more information about how to use LoadSim 2003, see Microsoft Exchange Server 2003 Load Simulator (LoadSim).

RPC over HTTP works best in combination with Microsoft® Office Outlook® 2003 in cached mode. You should always use cached mode with RPC over HTTP to perform the following tasks:

• Reduce the number of connections that Outlook has to make to the Exchange server.

• Insulate the client from Internet latency.

HTTP Sessions Established by Outlook by Using RPC over HTTP

For each RPC connection, Outlook initiates two HTTP sessions: one session for outgoing data and one session for incoming data. If Outlook shows five connections to the Exchange server for the Exchange mailbox, public folders, and the directory service, there are actually ten HTTP sessions. It is possible to fill the queue of concurrent kernel requests in the Internet Information Services (IIS) application pool. If the queue of concurrent kernel requests is filled, performance on Outlook clients may be negatively affected.

The following example shows how filling the queue of concurrent kernel requests in the IIS application pool affects performance. The default value of the kernel request queue limit is dependent upon the version of Windows Server 2003 used to enable IIS. If Microsoft Windows Server™2003 was used to install IIS, then the default kernel request queue limit is 4000. If Windows Server 2003 Service Pack 1 (SP1) or later was used to install IIS, then the default kernel request queue limit is 1000. In this example, each Outlook user has an average of five RPC connections. These connections can be to the Exchange mailbox, public folders, or to the directory service. If there are five Outlook RPC connections, Outlook has ten HTTP sessions per user. Therefore, 400 concurrent users, each with ten HTTP sessions, fill the queue. The addition of more users affects performance because IIS forcibly closes Outlook sessions. Outlook has to reopen the sessions that IIS closes.

For more information about how to view connections that Outlook currently has established, see How to View Established Connections in Outlook.

When you increase the value of the kernel request queue limit, you increase memory consumption slightly on the RPC proxy server. Windows Server 2003 Service Pack 1 (SP1) has improvements that reduce the memory overhead for increased kernel requests. If you want to increase the size of the kernel request queue limit, you must increase the limit on the RPC proxy server to approximately ten times the number of concurrent Outlook users that you expect to support on the server that has RPC over HTTP.

For more information about how to increase the size of the kernel request queue limit, see How to Increase the Size of the Kernel Request Queue Limit.

RPC over HTTP Scalability Limitations

The 32-bit version of Windows Server 2003 with SP1 is limited in the number of HTTPS connections it can reliably support based on kernel memory consumption; specifically Non Paged Pool memory. This limit is about 17,000-20,000 connections on a server configured without the /3GB boot.ini switch.

Based on the Outlook and HTTPS connection information provided above (5 Outlook connections using 10 HTTPS connections), a dedicated Exchange 2003 Front End RPC/HTTPS server could reliably service around 1700-2000 active Outlook 2003 clients connecting via RPC/HTTPS. For more details on Exchange 2003 and kernel memory, see Troubleshooting Exchange Server 2003 Performance.

Network Load Balancing

You can use Network Load Balancing (NLB) for redundancy and scalability. NLB distributes client requests across a set of servers. Exchange Server 2003 supports the use of RPC over HTTP with front-end servers that are NLB clusters.

The following table lists the types of client affinity that NLB supports.

If you use NLB on your front-end servers, you should use either Single IP affinity or Class C affinity to reduce the overhead of negotiating SSL sessions.

For more information about NLB, see Network Load Balancing Technical Reference.