Crawl performance on BDC application  
Author Message
Andrew Woodward MVP

PostPosted: SharePoint - Business Data Catalog, Crawl performance on BDC application Top

We have been working on a POC that involves a reasonably complex BDC mapping on the AdventureWorks2005 database. We are including about 10 entities with numerous associations.

The BDC generation was reasonable straight forward (one problem we had I will post about seperately) however I am finding the indexing of the content to be painfully slow. This is running on a single machine (so results will not be indicative of live) but we have found that it has taken over 4 hours to index 150,000 entities (works orders, products etc).

Also the SharedServices_Search database has grow to over 2GB which is a significant multiplier on the base data of about 170MB, do we have any numbers of this or is it totally dependent on the mappings, associations and if the crawed content is included in the index

Has anyone else found this problem Is this a BDC V1 issues or are we trying to do things with the BDC that it was not really built for

I have not done any SQL profiling (will if we get time).

Any help/pointers on performance improvements greatly recieved.


SharePoint Products and Technologies1  
andrew woodward

PostPosted: SharePoint - Business Data Catalog, Crawl performance on BDC application Top

Update/Additional information:

1. The actual index sizes are small 39MB (this in in line with the 40% of the content size guidance)

2. As the server was an 'out of the box' single installation the Indexer Performance was set to reduced, I have set to Maximium and will post the outcome (not recommended if you have real users).

3. SharedServices_Search database grew to 2.1GB but now has 500Mb free space (still 1.6GB of metadata though!)

The biggest tables were MSDocProps - 330MB and shrinking the database reduced it by a further 300MB. But 1.3Gb for this scenarios seems excess and I would like to (do if I have time) or see some metrics around this. We spend considerable time looking at sizing and this may be one area that gets overlooked, it would also be interesting to see how this compares to standard sharepoint content crawling.