So you want to know about High Item Counts and Restricted Views


If you've wanted to know more about why high item counts and restricted view requests can impact the performance of your Exchange environment, we've just released some detailed information about the behavior you may see as item counts in your critical path folders grow. Critical path folders include the Calendar, Contacts, Inbox, and Sent Item folders. Restricted views are data views that restrict information based on search criteria that result in views of only a subset of items in a folder. Performance issues related to these situations are frequently related and can become visible to end-users in the form of slow client access and the dreaded RPC dialog-box popping-up. It only takes a few users who have abnormally high item counts in their critical path folders to cause performance issues which are felt throughout your whole Exchange organization. Learn more about the issue in the topic Understanding the Performance Impact of High Item Counts and Restricted Views: http://technet.microsoft.com/en-us/library/cc535025(EXCHG.80).aspx

- Tom Di Nardo

Comments (12)
  1. Andy G says:

    Thanks for the post.

    On the subject of Outlook performance I would really appreciate some detail on the changes made in KB948828 (Error message when you enable the "Show in Groups" option) and the associated fix for the Outlook client. Have changes been made to the way the Store indexes mail items to improve performance when "Show in Groups" is enabled?

    Cheers :O)

  2. Mike Lagase says:

    – The fix server side was to allow for FindFastRow optimization. When the call came in from Outlook to request this view, the Information Store immediately switched to a SlowFindRow call. Once that occurred and due to the amount of items in the folder, it took a significant amount of time to generate this view. The store fix prevented the function call to switch to SlowFindRow.

    – The client side fix removes doing expensive FindRow calls and the associated restriction that is created when this option is enabled.

    Note: This only occurs in a online mode profile as cached mode profiles query the local OST instead of querying the store which is where the problem comes in.

    In addition, if the client fix is installed, Exchange 2007 does not exhibit this problem since this optimization is already there.

  3. Andy G says:

    Thanks for the response.

  4. Mark Valpreda says:

    So this SlowFindRow and FindFastRow optimization is done how? I have a slow Exchange 2003 server due to people with 8k-40k things in folders. I tell them to clean up, but they don’t listen…..

  5. adam says:

    Can you direct me to any posts that detail how high item counts affect cached-mode?  Does the same performance impact occur in cached-mode as online-mode?

  6. Mike Lagase says:

    Mark,

    If your users don’t listen, then you as an administrator need to do this for them by cleaning out their own folders using some means of archival or by the use of Mailbox Manager to move items out of their critical path folders.

    If they don’t keep item counts under 5,000 items or so, then they will at some point come to you stating that when I click on this folder, it took x amount of time to render that view and this is unacceptable

    If they are using the Show in groups option or doing any custom views outside of the defaults, then render time will take that much longer.

    Just think of this, when you click on a folder, we have to query every item in that folder before rendering the view back to the client and the more items you have, the more time it is going to take to generate that view. Unfortuantely, we don’t have any paged typed functionality to build the view in chunks currently, but we are doing some significant work in the next version of the products to minimize these problems.

    Identifying an Exchange server as slow can have 100 different root causes, so can you be more specific as to what slow means?

    If all else fails and you are still stuck, I would open a support incident to determine if the server slowness is a server side issue or it is a perceived issue on the client side.

  7. While I don’t really cover cached mode in detail in this topic, the issues you see in online mode are still there in cached mode, they are just shifted to the client (for the most part). If you’re client machines are not robust, then you may see significant
    performance degradation with high item counts. This paragraph touches on the issue with cached mode and item count:

    If you are running in cached-mode, (the default mode for Outlook 2003 and later versions), then client performance can be an issue as the number of items in a folder increases. One thing that you should do is keep your OST files (the local data cache) free
    of fragments. You can use the Windows SysInternals tool Contig for this purpose. To download the latest version of Contig, see Contig v1.54.

    I’m going to cover this in a little more detail in the Planning for Large Mailboxes with Exchange 2007 white paper that I’m hoping to release in July. In the interim, Matt Gossage has some good information in his Optimizing Outlook 2007 Cache Mode Performance
    for a Very Large Mailbox:
    http://msexchangeteam.com/archive/2007/12/17/447750.aspx

  8. Raymond Delshot says:

    Is the information also relevant to Exchange 2003 ?

  9. Andy G says:

    A note to anyone thinking about installing the "show in groups" server-side hotfix: take a look at KB951619 (http://support.microsoft.com/kb/951619) before installing as it looks like the "show in groups" hotfix will be affected by the issue, and therefore you should install 951619 instead.

  10. Mike Lagase says:

    This affects all current versions of Exchange

  11. RED says:

    How are restricted views affected by clients being in cached mode? Does Outlook only look at the local OST or does it look at the server for the view or does it do both? Thanks.

  12. tdinardo says:

    Cached-mode clients, in most circumstances, will take the perf hit on their local machine for view presentation. The issue can be shifted back to the server for requests for information that are not cached, for example multi-delegate meeting requests where calendar information must be pulled. In that case, a view must be processed server-side. However, in most cases, this is a minor number of requests, so the impact should be minimal. Keep in mind that as item counts per-folder increase in an OST scenario, the disk performance of the local machine can be a significant limiting factor, so fast hard-disks are a must with large OSTs and high item counts.

Comments are closed.

Skip to main content