Performance is usually on back of mind when I do typical chores of a Lead/Architect on any project. Unfortunately, with tighter timelines and supreme focus on getting the tasks done with out even us realizing if often takes a back seat. But, we all need to strive for excellence and the only way you would be able to deliver a quality solution is with a legit key if performance were a lock. 🙂
Performance has that good spot on a quality solution checklist as none of the users like waiting in this fast pace world. I was taking a look back in my blogging and found this one here where I wrote my heart out on some tips that can improve your Sitecore solution in general, this time around I will be adding some personal learning on this current Coveo for Sitecore I am part of where performance is a lock 😉 and in my quest to find a key, I actually found a bunch of things you could do to top off what I already knew. Again, thanks to awesome @Coveo team who always supports the goals and challenges of the integration project and trust me they are never the same, with a different client comes different set of challenges. But, that is the fun right?
Now, enough of the story, lets jump right in to the details. I do not like to repeat what Coveo already recommends, so, I will point you all to right resources where I can.
- Case 1: When what you have on Sitecore is simply not enough!
You have couple of options here to battle this. Which path you would choose usually depends on type of data that you are after. What is the latency tolerance on the piece of data? Is context involved? Do we fetch from third party or is it drawn from business logic based on existing data on your sitecore? When you answer these you could pick the option right that would actually affect your performance in a good, bad or ugly way depending on what you choose.
If the additional information is user context driven then the processor Coveo offers is way to go. You can find more information here
If you can live with latency or is tolerable and logic is quite complicated to place in processor noted above, then, computed fields is way to go. You can read more information here, this usually comes with an additional step to ensure your data is fresh especially if your computed fields are drawn from a third party source as Sitecore publish might not refresh some of your data. The additional step is to actually rebuild a specific area of your content tree in a scheduled manner. With Coveo 5, you can use the Index API and fire a special crawler. See more info here, do not forget to configure your new crawler first to keep the scope to what you care about as we all know indexing is a quite expensive operation. If you did not know how to, here is the link to do the same.
So, choose your path wisely and that will put rest of performance in check. - Case 2: So, yeah, you cant show everything
This is like almost always right? There is bunch of content on Index, but, we cant show everything in every case. May be some items are only for special group of users or may be we want to show only content items of specific template. I did this like so many times in the past, but, never looked at it from performance lens, when Coveo mentioned we could improve performance with some simple configuration settings on the filters we plan to use, it made be re-read this document here to find what I just skimmed through in my last read. There are so many good/easy settings you can use to improve performance on these filters. Read more here - Case 3: Oh boy, you have loads of data on Index
I guess any enterprise Sitecore solution would have ton of content, but, we do not want all of it on Coveo Indexes, when you think about it, what you would show on Coveo search interface to user would need to be a page, so, why bother pushing items to index that do not have presentation, right? In most cases that is true unless you have a very different content strategy and link modifications on Sitecore, in these cases we cant exclude all items minus presentation as a default. You can read how to do this here
In our case, we could not do this, so, had to clean up some not needed data on Index via inclusion/exclusion rules of templates. You can read more about this here
As we roll along with implementation, I am sure we will learn more and more ways that Coveo provides to keep the performance in check. Again, it was so greatly satisfying to keep learning new things with every implementation. Hope this helps some one who is looking for more ways to enhance performance of their Coveo for Sitecore implementation. This is just a scratch on surface per me, what I would recommend is to work with Coveo team for project specific tricks you could do to ensure Coveo works and behaves as cool as it should be.