This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit

eZ Community » Learn » eZ Publish » Need for speed - How to use eZ Find...

Need for speed - How to use eZ Find search fetch instead of standard content list/tree fetch

Tuesday 13 July 2010 10:27:45 am

  • Currently 5 out of 5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Step 1: Understanding the basic notions

Before digging in it is important to know few things.

The very first thing

The first thing you need to be aware of is that eZ Find is using database of its own, based on the well known Solr/Lucene search engine. More info on Solr can be found here: A citation from that web page:

“blazing fast open source enterprise search platform”

So the content needs to be indexed (transferred to Solr database) every time it is created or changed. If for some reason the indexation process fails you will not have up-to-date data in the index.

The indexation task is carried out by eZ Find search plugin. There are 3 ways how it can be configured:

  • after publish (drawback is that it burdens the publish process)
  • delayed to cronjob (drawback is that the index is always lagging behind so it may happen that query results are not 100% correct)
  • a combination of first two (new in eZ Find 2.2) with DisableDirectCommits option. Publish is faster as indexing is queued within Solr and not done immediately (process is commited every CommitWithin seconds)

There is no silver bullet solution in choosing from these 3 options, as it depends on the way you are using search functions. If results need to be up-to-date then DelayedIndexing option in ezfind.ini should be disabled. In that case for faster publish DisableDirectCommits and CommitWithin could be used.

Good practice would be to launch complete reindexing every week just to be sure, because various things can go wrong here: external tools for binary files can break, etc.

The second notion, about optimization

Second important thing is the ‘optimize’ function. Optimize does exactly what the name suggest, basically it merges more Solr segments (created by update, delete, etc.) into one and by doing so makes searching faster. Recommendation would be to schedule this with cronjob as it’s not important to be executed right after content is changed. Therefore OptimizeOnCommit option in ezfind.ini should be disabled.

Solr optimization process



Printer Friendly version of the full article on one page with plain styles


Proudly Developed with from