1) When working with lots of data, first search to get the HREFS of the items, then use the HREFS to work with the individual items. The batch processing verbs (BPROPFIND, BPROPPATCH, etc) work well with these. -this will usually give much better performance.
2 When at all possible, use of batch methods: BPROPFIND, BPROPATCH, etc.
3) Don't “SELECT * ” when doing searches. This is costly performance wise. Only retrieve
back what you need.
4) Sniff OWA to see how it does its searches and the types of WebDAV calls it does.
5) Avoid searching non-indexed fields.
6) Ok... Exchange is not email warehouse...
If you have anywhere near 10,000 items in the folder being serached, then you will run into
performance issues. You need to reduce the number of items in the folder - this is a given.
Once you get near this number of items, speed for many operations including seraches will
take many times longer (anywhere from 50%-600%+ slower from what I've seen on many
different systems). This is not a WebDAV limitation - its for ANYTHING which works against
Exchange items/folder - especially when seraching. Exchange is an email server - not a
database, so you should not assume that it have performance behavior which parallels SQL
you should not assume that it have performance behavior which parallels SQL
database. This is probably the biggest of all performance killers. So, if you have anywhere near
10,000 items, then you should re-think storing so many items in a folder and look at chaning that
folder's usage to reduce the number of items, move the content to SQL Server, custom store provider
or some other solution.
7) Authentication communication:
a) Firewall, exchange virtual directory and authentication method being used need to be
lined-up for optimal performance.
b) Have the virtual directory used in the DAV call support only the protocol you are using. If the virtual directory has both windows and basic authentication turn on and port 88 is blocked,
you will run into a delay.
c) If you use the XML DOM, you should use the XMLServer HTTP and not INet (client) if the DAV code
is running from a server. SSL has a slight slowing effect.
d) Asynchronous vs Synchronous communication: Asynchronous will have higher performance and will
help avoid lockups when the DAV processing is taking a long time. Synchronous is easier to write and debug.
e) Network issues can slow calls.
8) In terms of speed in doing the calls, you should get the best performance with .NET, followed by the XML DOM and then SAX
9) .NET has additional Credential Caching capabilities and has additional authentication settings - see the PreAuthenticate property of the web request for more information.
10) You may want to consider using full text index searches. Below is an article covering this.
XWEB: How to Perform Full-Text Searching Using WebDAV
11) Limit search criteria;
12) Sort on the client and not in the WebDAV Search.
13) Firewalls, proxies and antivirus can slow down searches. Try running directly on the server and note the performance difference.
14) Searching calendars causes expansion of recurring calendar items (meetings/appointments). Expanding items involves creation of a work-.eml file being created for every day the calendar item occurs.
15) Searching on calculated fields can increase search time.
16) With Exchange 2000/2003 items exist in two stores - one for MIME and one for properties. Information in these stores is synced on an as-needed basis - thats because such syncing is resource intensive. If you search for or againt fields which have not been put into the property store, then Exchange will have to sync the information on those items in order to complete the search.
17) If your using a third party API, you might use netmon to sniff the traffic to see what is being sent by the API. This may provide clues as to where the problem is.