Most Microsoft Exchange Server applications get and set properties frequently. You can significantly improve application performance by making this process as efficient as possible.
Each GetProps call generates an RPC that results in an average of 260 to 300 bytes of network overhead in addition to the bytes of data sent. This overhead has a performance impact, particularly on users with slow links or modems. For example, an application designed to read a message by retrieving each of its properties separately requires 10 to 12 RPCs for each message, which results in 3000 bytes of overhead per message. Using more efficient methods noticeably improves the performance of this type of application.
Note Getting properties that are stored on the local computer does not cause an RPC. For a list of these properties, see Using Local Properties and Building a Cache of Frequently Used Items.
Besides using local properties, you can group information that may generate an RPC into a single call. Server-based services generally attempt to batch as many calls as possible, but rewriting your client application to group them into one call is a good way to reduce the overhead.
You can eliminate RPCs by designing your client application to process only those properties that are required. Determine the minimum set and take advantage of the fact that the server often returns multiple properties when queried for a single property. Querying all properties whether or not they are needed is generally not a good strategy.
Functional overhead is also incurred each time you set a property with the SetProps method. It is a good idea to design your client application to gather as many properties as possible before setting them on the server.
A provider such as the Microsoft Exchange Server information store can collect a number of SetProps requests at the client and store the cached information until an RPC is forced by a call such as the IMAPIProp::SaveChanges method. It then writes all the changes at once. This greatly reduces overhead for SetProps calls.
A client application sends a message and saves a copy of the message in a private folder. The current design requires three calls to SetProps. This number is reduced when the provider caches these SetProps requests and makes one call when the message is submitted. This results in only one RPC. A better solution is to rewrite your client application to group its own SetProps requests into one call. This reduces CPU usage more than the first solution because fewer total function calls are made.