5

As per blogs and best practices of Sitecore, its advised that fast queries should be avoided. The reason for that is fast queries will directly access the DB and fetch the results which causes overhead in performance if too many requests comes, mainly in production.

Normal Sitecore queries will take from indexes and have cache mechanism implemented.

  • So if I fast query an item with 100 children will all those come in to memory without paging or caching?

  • If normal queries are fetching from indexes where these indexes are stored and what indexing strategy they are following?

8

Everything that @Hishaam said is correct, but I want to clarify the 2 questions here:

So if I fast query an item with 100 children will all those come in to memory without paging or caching?

No - if you fast query a single item, you will get a single item. If your fast query adds children or all descendants you will get what you asked for. This is the same whether you do a standard or fast query.

If normal queries are fetching from indexes where these indexes are stored and what indexing strategy they are following?

Normal queries are not fetching from an index, they are still using the database, but they are put through layers of caching. On a cold start, fast query might be faster, but after the first call, a normal query (unless a crazy one) can be faster because of the caching.

So what about indexing?

The third option to get data out is the content search API. This does use either a Lucene, Solr or Azure Search index to get the data. It is very fast and the best method to use to get data unless you know the Id of an item. @Hishaam's post covers the typical strategies for updating those indexes.

3

When using Sitecore Fast Query, the result will not be cached. Sitecore has different layer of caching

http://learnsitecore.cmsuniverse.net/Developers/Articles/2009/07/CachingOverview.aspx

So if I fast query an item with 100 children will all those come in to memory without paging or caching?

If you use fast query, it will bypass all those levels of cache and hit the database directly because Sitecore Fast Query converts all the query conditions into SQL statements.

Fast query is faster on the first call than Sitecore query. But the next time, it will be slower than Sitecore query because it will need to hit the database again while Sitecore query will hit the cache.

If normal queries are fetching from indexes where these indexes are stored and what indexing strategy they are following?

Indexes are different from cache. Sitecore has 2 types of index provider: Lucene and Solr. When you query the indexes, it will not query the database but instead the lucene file indexes which are stored on the server or the Solr cores from the solr server.

The index strategies differ for each database and requirements.

Master Indexes Strategy

We tend to use the SyncMaster strategy because when content author performs changes on the Content Editor, the master index will get updated once the item is saved.

Web Indexes Strategy

For web indexes, normally, we tend to use onPublishEndAsync. This stratgey will trigger the rebuild of indexes once a publish has completed.

References

  • 1
    Also its worth noting, that a fast query will return results in database order, which is most likely different to the order the items are stored in the Sitecore tree, this can lead to unexpected behavior. AND normal queries are not using an index - I've added an answer to clarify – Richard Seal May 31 '18 at 12:27
  • 1
    This answer does more harm than good. First of all, Fast Query is very rarely faster than regular Sitecore Query on anything but your development box. Secondly you bring indexes into the answer, which has no bearing on Sitecore Query only Sitecore ContentSearch. – Mark Cassidy May 31 '18 at 15:12
  • @MarkCassidy i brought indexes since the OP mention about query indexes and most blog I’ve read they say fast query is faster than sitecore query – Hishaam Namooya May 31 '18 at 15:14
  • Fast query always hits the database, regular query uses the item cache. First query might be initially slower but afterwards it's fetching from cache. On a production environment, every request fetching data from database using a fast query will put too much load on the DB. – jammykam May 31 '18 at 17:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.