indexing - Difference between Sitecore solr index rebuild and refresh -


we know difference between sitecore full index rebuild , index refresh. when want refresh item in index took ~2 min. full rebuild of master index took ~10min. why index refresh time consuming?

we refreshing item using code:

sitecore.data.item item = getitem(); var masterindex = contentsearchmanager.getindex("sitecore_master_index"); masterindex.refresh(new sitecoreindexableitem(item)); 

i'm looking in decompiled source of sitecore.contentsearch assembly , looks refresh method calls refreshtree method on indexcustodian class. refreshtree create new object array item indexed , iterate through available indices (even though you've called specific index) , creating refresh job each of them (which added queue processing):

public static ienumerable<job> refreshtree(iindexable startitem) {     assert.argumentnotnull(startitem, "startitem");     crawlinglog.log.debug(string.format("indexcustodian. refreshtree triggered on item {0}.", startitem.absolutepath), null);     return          index in contentsearchmanager.indexes         select indexcustodian.refresh(index, startitem); }  public static job refresh(isearchindex index, iindexable indexable) {     assert.argumentnotnull(index, "index");     assert.argumentnotnull(indexable, "indexable");     object[] objarray = new object[] { indexable };     joboptions joboptions = indexcustodian.getjoboptions(index, "refresh", objarray, true);     joboptions.customdata = indexable;     crawlinglog.log.debug(string.format("indexcustodian. refresh triggered on index {0}. data={1}", index.name, joboptions.customdata), null);     return jobmanager.start(joboptions); } 

the fullrebuild method (also in indexcustodian) calls createrebuildjob direcly creates 1 job processed:

public static job fullrebuild(isearchindex index, bool start = true)     {         return indexcustodian.createrebuildjob(index, new eventhandler<jobstartedeventargs>(indexcustodian.rebuildstartedhandler), new eventhandler<jobfinishedeventargs>(indexcustodian.rebuildfinishedhandler), start, null);     }  private static job createrebuildjob(isearchindex index, eventhandler<jobstartedeventargs> startedhandler = null, eventhandler<jobfinishedeventargs> finishedhandler = null, bool start = true, object[] parameters = null)     {         assert.argumentnotnull(index, "index");         joboptions joboptions = indexcustodian.getjoboptions(index, "rebuild", parameters, false);         job job = new job(joboptions);         if (startedhandler != null)         {             job.started += startedhandler;         }         if (finishedhandler != null)         {             job.finished += finishedhandler;         }         if (start)         {             crawlinglog.log.warn(string.format("indexcustodian. fullrebuild triggered on index {0}.", index.name), null);             jobmanager.start(job);         }         return job;     } 

so refresh method has overhead iterating through indices , dependent on jobmanager queuing , processing refresh jobs (multiple if several indices have been found).


Comments

Popular posts from this blog

c++ - Difference between pre and post decrement in recursive function argument -

php - Nothing but 'run(); ' when browsing to my local project, how do I fix this? -

php - How can I echo out this array? -