I understand. Have you looked at Mark's patch? From his performance tests, it looks pretty good.
When would RA work better? Bill On 8/14/11 8:40 PM, "Nagendra Nagarajayya" <nnagaraja...@transaxtions.com> wrote: >Bill: > >The technical details of the NRT implementation in Apache Solr with >RankingAlgorithm (SOLR-RA) is available here: > >http://solr-ra.tgels.com/papers/NRT_Solr_RankingAlgorithm.pdf > >(Some changes for Solr 3.x, but for most it is as above) > >Regarding support for 4.0 trunk, should happen sometime soon. > >Regards > >- Nagendra Nagarajayya >http://solr-ra.tgels.org >http://rankingalgorithm.tgels.org > > > > > >On 8/14/2011 7:11 PM, Bill Bell wrote: >> OK, >> >> I'll ask the elephant in the roomŠ. >> >> What is the difference between the new UpdateHandler from Mark and the >> SOLR-RA? >> >> The UpdateHandler works with 4.0 does SOLR-RA work with 4.0 trunk? >> >> Pros/Cons? >> >> >> On 8/14/11 8:10 PM, "Nagendra >>Nagarajayya"<nnagaraja...@transaxtions.com> >> wrote: >> >>> Naveen: >>> >>> NRT with Apache Solr 3.3 and RankingAlgorithm does need a commit for a >>> document to become searchable. Any document that you add through update >>> becomes immediately searchable. So no need to commit from within your >>> update client code. Since there is no commit, the cache does not have >>> to be cleared or the old searchers closed or new searchers opened, and >>> warmed (error that you are facing). >>> >>> Regards >>> >>> - Nagendra Nagarajayya >>> http://solr-ra.tgels.org >>> http://rankingalgorithm.tgels.org >>> >>> >>> >>> On 8/14/2011 10:37 AM, Naveen Gupta wrote: >>>> Hi Mark/Erick/Nagendra, >>>> >>>> I was not very confident about NRT at that point of time, when we >>>> started >>>> project almost 1 year ago, definitely i would try NRT and see the >>>> performance. >>>> >>>> The current requirement was working fine till we were using >>>> commitWithin 10 >>>> millisecs in the XMLDocument which we were posting to SOLR. >>>> >>>> But due to which, we were getting very poor performance (almost 3 mins >>>> for >>>> 15,000 docs) per user. There are many paraller user committing to our >>>> SOLR. >>>> >>>> So we removed the commitWithin, and hence performance was much much >>>> better. >>>> >>>> But then we are getting this maxWarmingSearcher Error, because we are >>>> committing separately as a curl request after once entire doc is >>>> submitted >>>> for indexing. >>>> >>>> The question here is what is difference between commitWithin and >>>>commit >>>> (apart from the fact that commit takes memory and processes and >>>> additional >>>> hardware usage) >>>> >>>> Why we want it to be visible as soon as possible, since we are >>>>applying >>>> many >>>> business rules on top of the results (older indexes as well as new >>>>one) >>>> and >>>> apply different filters. >>>> >>>> upto 5 mins is fine for us. but more than that we need to think then >>>> other >>>> optimizations. >>>> >>>> We will definitely try NRT. But please tell me other options which we >>>> can >>>> apply in order to optimize.? >>>> >>>> Thanks >>>> Naveen >>>> >>>> >>>> On Sun, Aug 14, 2011 at 9:42 PM, Erick >>>> Erickson<erickerick...@gmail.com>wrote: >>>> >>>>> Ah, thanks, Mark... I must have been looking at the wrong JIRAs. >>>>> >>>>> Erick >>>>> >>>>> On Sun, Aug 14, 2011 at 10:02 AM, Mark Miller<markrmil...@gmail.com> >>>>> wrote: >>>>>> On Aug 14, 2011, at 9:03 AM, Erick Erickson wrote: >>>>>> >>>>>>> You either have to go to near real time (NRT), which is under >>>>>>> development, but not committed to trunk yet >>>>>> NRT support is committed to trunk. >>>>>> >>>>>> - Mark Miller >>>>>> lucidimagination.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >> >> >> >
