Remember that your application is not the only one going against the server, so play nice. You may be able to get needed performance in your application but when other applications are going against the server in the real world you may find that the overall experience for all users on that server are poor. I've seen applications which try to consume an insane amount of data at one time because they are only concerned about their performance for the user of their application. Later they find that when many users are using the same application at the same time that the Exchange server involved comes to a grinding halt. Such issues by these applications ore one of the main reasons for all the work on throttling on Exchange. Always keep in mind that throttling is there to help keep proper a reign on applications which would otherwise dominate a server - its your friend. Note though that while throttling has gotten pretty extensive by sure need that it won't account for every performance issue caused by applications and non-performant searches are one of the biggest causes of performance issues with Exchange servers.
Take your time to think of how your building your search and consider the following as each one of these points can have a major impact on performance.
- Indexes which might be used for finding the items.
- The amount of search criteria which is used.
- The size and type of data which will need to be checked.
- The number of items in the mailbox/folders being searched.
- How deep you are searching.
- How much information you are requesting.
- How much data you are returning at a time.
- If you need to sort on the server.
- Would it be better to create a Search Folder?
- Would it be better to create a custom property on each item to search against rather than search many different properties to locate an item?
- Instead of doing searches would it be better to use a synch mechanism such as EWS Streaming Notifications?
Here are some pointers on searches with EWS:
- Exchange 2013 has indexed fields and many fields automatically indexed based upon how often they are searched and indexing is geared to the type of searches OWA and Outlook make on a normal basis.
Message properties indexed by Exchange Search
- The overall rule for searching is to request the item ID in the initial search. From there pull back additional properties as needed. Asking for all properties, a large set of them or large ones such as body, attachments and MIME will put a load against Exchange and will slow getting a response. So, avoid pulling such unless you absolutely need to. Asking for more than is needed at any time should be avoided. Less is more.
- As noted above you want to usually pull back the least you need, so asking for all properties should be avoided. When you need to pull back properties you should pull only the exact properties you need. requesting all properties won't really give you all properties anyway - it just gives you back the most common and is usually best suited for when you want to explore what can be returned.
- Be aware of the differences between searching the calendar for items in it versus using a calendar view. A calendar view will expand recurring calendar items between a date range. If you just search the calendar for items then you will be going against the calendar item masters and not each instance.
- If your getting timeouts then consider traversing the folder structure and do a search per folder. Moving overloaded folders into separate folders will help also with load an individual response times as there would be less to go against while searching.
- Always pull back results paged when possible. This prevents a lot of data being returned back at one time and possibly impacting performance or causing a timeout.
- Consider creating a custom search folder if there are fields which are often used in searching. You would create the folder and use it to search against. The way it works is something like a database view, which has items pre-filtered based on restriction criteria.
- Be aware of issues with searching the "Allitems" folder. The "Allitems" folder is an application search folder used by Outlook - its not a standard folder. The basic definition of it is a deep search which includes everything with an item class. Such a folder will have a lot of results. Some developers want to search it, however its better to not do that and use a custom search folder or traverse each folder and search. In a heavily populated mailbox while doing any sort of a complex search against "Allitems" or ones against properties like a message body its easy to get a timeout error - so, doing such a direct search against may not scale to fit all your needs. So, in other words be careful on how you construct you search and how many items and overall data the server must dig through.
- Repeated calls against the same folder may appear to be the same speed in Exchange 2013. This is because the results are no longer cached.
- Try to sort your data on the client rather than the server to avoid taxing the server.
EWS Best Practices - “AllItems” folder
http://blogs.msdn.com/b/webdav_101/archive/2015/05/03/ews-best-practices-allitems-folder.aspxIts extremely important to understand throttling limits which will affect your code should it violate a throttling policy limit.
EWS throttling in Exchange
- Consider using eDiscovery to search multiple mailboxes. This is an Administer level search which does require a special RBAC to granted to the account use with EWS.
eDiscovery in EWS in Exchange
Exchange 2013: eDiscovery Changes
- There are samples written in C# which show how to implement several types of seraches in EWSEditor's code. There is also logic covering working with calendars.
EWS throttling in Exchange
Repeated calls against the same folder are slow in Exchange Server 2013
EWS throttling in Exchange
Throttling Policies and the EWSFindCountLimit
Recommended Mailbox Size Limits