You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Erick Erickson <er...@gmail.com> on 2013/11/19 19:19:29 UTC

TermsComponent question

I have a situation in which the speed of the TermsComponent varies pretty
radically and wanted to air a theory just to see if it is possible of
whether I'm going off the deep end:

The symptom is, that _without_ committing, the response time from the
TermsComponent varies very widely. Searching for the "abc" prefix will take
a while the first time. Then it's fast. Then, without any commits, it gets
slow again if you wait for a while.

This is a _very_ high I/O environment for the Solr in question. So my
theory is that the pages containing the terms get swapped out if the terms
component isn't hit very frequently and what we're seeing is a result.

Off the top of people's heads:
1> does this sound remotely plausible?
2> if <1> is "yes", any suggestions on how to verify?
3> if <1> is "no", any clue where to look next?

Thanks!
Erick

Re: TermsComponent question

Posted by Areek Zillur <ar...@gmail.com>.
You can use the Suggester in SpellcheckComponent, or the new Suggester
Component (once it gets committed), if you are trying to do prefix
searching. The only issue is you have to build the suggesters with the
terms to get the suggestions (it will not update itself when you update
documents [you can use buildOnCommit to mimic that (not recommended if you
have a lot of updates?)])


On Tue, Nov 19, 2013 at 10:23 AM, Erick Erickson <er...@gmail.com>wrote:

> replying to myself. Or is this just silly and instead of using the
> TermsComponent would autosuggest just fix it all up?
>
>
> On Tue, Nov 19, 2013 at 1:19 PM, Erick Erickson <er...@gmail.com>wrote:
>
>> I have a situation in which the speed of the TermsComponent varies pretty
>> radically and wanted to air a theory just to see if it is possible of
>> whether I'm going off the deep end:
>>
>> The symptom is, that _without_ committing, the response time from the
>> TermsComponent varies very widely. Searching for the "abc" prefix will take
>> a while the first time. Then it's fast. Then, without any commits, it gets
>> slow again if you wait for a while.
>>
>> This is a _very_ high I/O environment for the Solr in question. So my
>> theory is that the pages containing the terms get swapped out if the terms
>> component isn't hit very frequently and what we're seeing is a result.
>>
>> Off the top of people's heads:
>> 1> does this sound remotely plausible?
>> 2> if <1> is "yes", any suggestions on how to verify?
>> 3> if <1> is "no", any clue where to look next?
>>
>> Thanks!
>> Erick
>>
>
>

Re: TermsComponent question

Posted by Erick Erickson <er...@gmail.com>.
replying to myself. Or is this just silly and instead of using the
TermsComponent would autosuggest just fix it all up?


On Tue, Nov 19, 2013 at 1:19 PM, Erick Erickson <er...@gmail.com>wrote:

> I have a situation in which the speed of the TermsComponent varies pretty
> radically and wanted to air a theory just to see if it is possible of
> whether I'm going off the deep end:
>
> The symptom is, that _without_ committing, the response time from the
> TermsComponent varies very widely. Searching for the "abc" prefix will take
> a while the first time. Then it's fast. Then, without any commits, it gets
> slow again if you wait for a while.
>
> This is a _very_ high I/O environment for the Solr in question. So my
> theory is that the pages containing the terms get swapped out if the terms
> component isn't hit very frequently and what we're seeing is a result.
>
> Off the top of people's heads:
> 1> does this sound remotely plausible?
> 2> if <1> is "yes", any suggestions on how to verify?
> 3> if <1> is "no", any clue where to look next?
>
> Thanks!
> Erick
>