You can implement your own queue if you like. Create your own implementation of "EPiServer.Find.Cms.ContentChangedEventStore", and register it in the IOC container (initialization module). The reason it's slow is because it involves a SQL database.
I have also written about some settings that can be set for the queue here: http://world.episerver.com/forum/developer-forum/EPiServer-Search/Thread-Container/2017/2/find-commerce-and-service-api/?pageIndex=1#reply
The setting indexingQueueBatchSize has a defaultvalue of 500.
I performed the following test:
Why are the the rows processed one by one, and not in batches of 500?
How about not using the Find index queue and just hooking into content events and submitting changes to the IClient.Index() right away?
Hi
I got some code from Episerver regarding this to speed up the Que, but the class to inherit from, ContentChangedEventStore, does not exist in our EPiServer.Find.Cms namespace.
Am I missing something or do we have the wrong version of Find?
Find .NET API-version: 11.0.0.3701
When an episerver page is published or edited, a reference to the page is added to the SQL table tblFindIndexQueue and then the rows in this table are processed.
At some periods of the year our editors publish a large number of large documents (equal to some hundred A4 pages each), and the indexing queue grows large because its items are processed quite slowly.
If we do a full reindex using "EPiServer Find Content Indexing Job" large documents like this are reindexed much, much faster. Is there any settings, or magic, that can speed up the slow indexing queue?