We've been able to programatically setup a scheduled task to run that automates our synchronization of content from staging to production.

Now our issue is with the smartsearch indexing which causes slowdowns with on production. We've determined that everytime the sync runs, production tries to re-index each change and our guess is that if there are a lot of tasks, the search constantly tries to re-index each item in the queue and eventually timesouts and takes up a lot of cpu time bringing the server to a crawl.

We've found that we can solve this by disabling the smartsearch, let the sync run, re-build the index when the sync is done and then re-enable the smartsearch again.

Our problem now is figuring the optimal way to schedule all this. The sync is not a problem since we already have this, but this kickoffs on staging. How can I disable, re-index and re-enable the smartsearch features on production when the sync runs on staging?

One idea was to use a standard .net data connection to production and change the record for the smartsearch value to disable it before we execute the sync. Then after the sync completes, we write a value to a custom field, also from staging, to note the completion of the sync.

Meanwhile on production, we would run a check every few minutes on that field to see if it's been populated with a value denoting the completion of the sync. At this point, we can then re-build the index (since it would already be disabled as noted earlier) and then re-enable the smartsearch.

This all sounds ok in theory but just seems a bit tedious to have to run 2 scheduled tasks on 2 web servers just to resolve our timeout issues because of the sync. Does anyone have a cleaner routine to do this?

Is there anyway to handle all of this directly from staging without needing to run 2 scheduled tasks?