If you are migrating from Sitecore 8.x to 9.3, you are using SXA and “query” datasources you should have a quick look here!

After we finished with our Sitecore upgrade (among with all the other upgrades, like .NET framework, GlassMapper, SXA, etc, more about this soon) and the QA team finished with the fantastic job of regression we were ready for our KPI tests.

One of the most challenging and important KPI for our client is the server performance, for that we usually run load and stress tests on our pre-prod environments, (more about performance testing soon). We started to get the Azure logs flooded with this exception:

AzureSearch Query [sitecore_web_index]: search=This_Is_Equal_ConstNode_Return_Nothing

This was happening on each and every request several times, even with our custom indexes, so of course affecting the performance at server side.

In order to confirm this first assumption, I started by getting a profiling session, I’ve used Azure Diagnostic Tools to collect a profiler trace:

Here we go 🙂 as I expected the hotspot was pointing to the related error message in the logs:

I did a lot of research in the internet and couldn’t find anything that helped me pointing out what was going on. So.. hands to work!

As it was happening on all pages types, so that was my first clue, it had to be on a global component, let’s then why not start with the footer and header page designs?

As I mentioned before, our sites are using SXA and we have some queries and tokens (like $site) as datasources to support muli-site, that was my starting point then:

Seems like after the upgrade, something changed and now Sitecore and SXA are conflicting with those tokens when using a query as datasource.

What got changed on Sitecore or SXA?

After a full config comparison between my previous instance and the new 9.3 one, I noticed this new processor has been introduced (GetDatasourceItemByQuery) in the Sitecore.ContenSearch.config file:

So, let’s have a look at this dll and see what is that doing!

Yay! found it! So, it is now making use of content search to resolve the datasource queries. Sounds like a good improvement, but, unfortunately not for my project, as seems like is not expecting to have a SXA token there.

Next steps: I opened a support ticket to Sitecore and SXA confirmed this issue and said they had fixed it in SXA 10.0. I’m still waiting for a hotfix for 9.3 as our client is not upgrading to 10 yet.

After I removed this processor, I ran my performance tests again and it got improved, another profiling session confirmed that the bottleneck was gone.

I hope you find this useful in case you face the same issue, happy upgrade!