11May, 2022
The Case of the Test Index That Just Wouldn't Stop Rebuilding
We've got a client with a really cool search implementation, and they're always excited to publish new content and see how our various CTAs dynamically pull data based on this or that. So, once the site started to really get going with content, we were getting requests about content not getting indexed. After a couple of initial checks, it turns out the sitecore_suggested_test_index was clogging the pipes! Why? How?
Checking Running Jobs
When I first started with Sitecore I actually thought you had to keep the indexing modal open in a browser! In fairness, I had someone senior to me also say, “Yeah I keep that window on my side monitor until it's done”. Ugh. It's humbling to share stories like these. Everyone hides them. Even you!!!
Moving on. When looking at the jobs viewer (/sitecore/admin/jobs.aspx) I see the issue. Why is the test index queued up so much? It turns out it's scheduled to run hourly as the data is needed for multivariate test recommendations, which is calculated from data in the reporting database (which is constantly getting updated). The scope of this is the entire content tree, which can take over a day in some cases, and putting a demand on SQL.
Dropping the Demand on Indexing
We don't need this index to be refreshed this often, and based on the queue above, this instance needs to be scaled up to meet the demand. Go to the item “Rebuild Suggested Tests Index “ under /sitecore/system/Tasks/Schedules/Content Testing/, or just search for {44428794-05A4-4BE6-90D6-7D0BF128D17E} to see the scheduled task.
The default value in the Schedule field will be once per hour. I'll just put it here instead of in the image above so the ol search engine finds it.
20140101|99990101|127|1.00:00
Now, it's up to you what to do here. There are clients that remove the schedule altogether by emptying this field since they don't use M/V testing, and others who will drop the iteration frequency rather than put more resources into indexing. Either way, the hourly index needs to be altered for other indexes to rebuild or update.
Once the queue was cleared up, authored content made its way through, and content appeared in query results a whole lot faster.
