> [Cedric: Yes]
>
>> However I can't figure out why some of these queries are slower. Some
>> are complicated queries, yet others are just simple single term
>> queries and doesn't seems to score lots of hits. There's no
>> correlation between the number of terms or number of hits with the
>> respo
On Wed, 2008-08-20 at 21:58 +0800, Cedric Ho wrote:
Toke:
> > Is it the same queries that are slow each time?
[Cedric: Yes]
> However I can't figure out why some of these queries are slower. Some
> are complicated queries, yet others are just simple single term
> queries and doesn't seems to scor
Hi Toke,
>> Search response time. We used the search log from our production
>> system and test it with SSD. The results shows that 75% of queries
>> returns within 1 second, 90% returns in 2.5 seconds, the remaining 10%
>> ranges from 2.5 seconds to less than 100 seconds.
>
> Are the sub-second r
Hi eks,
On Wed, Aug 20, 2008 at 3:04 PM, eks dev <[EMAIL PROTECTED]> wrote:
> The simplest sorting would be to sort your collection before indexing,
> because Lucene will preserve order of added documents I think nutch sorts
> index afterward somehow, but I do not know how this works
The way
On Wed, 2008-08-20 at 00:25 +0800, Cedric Ho wrote:
> Search response time. We used the search log from our production
> system and test it with SSD. The results shows that 75% of queries
> returns within 1 second, 90% returns in 2.5 seconds, the remaining 10%
> ranges from 2.5 seconds to less than
/jira/browse/LUCENE-1340
- Original Message
> From: Cedric Ho <[EMAIL PROTECTED]>
> To: java-user@lucene.apache.org
> Sent: Wednesday, 20 August, 2008 3:28:36 AM
> Subject: Re: Are there any Lucene optimizations applicable to SSD?
>
> Hi eks,
>
> My i
Hi eks,
My index is fully optimized, but I wasn't aware that I can sort it by
fields in Lucene. Could you elaborate on how to do that?
By omitTf(), do you mean Fieldable.setOmitNorms(true)? I'll try that.
Thanks,
Cedric Ho
>
> if you have possibility to sort your index once in a while on somet
hi Cedric,
has nothing to do with SSD... but
>
> All queries involves a Date Range Filter and a Publication Filter.
> We've used WrappingCachingFilters for the Publication Filter for there
> are only a limited number of combinations for this filter. For the
> Date Range Filter we just let it r
Hi,
Thanks for the reply =)
>
> What aspect of performance do you find lacking? Is it searching or
> indexing? While we've had stellar results for searches, indexing is just
> so-so better than conventional harddisks.
Search response time. We used the search log from our production
system and te
On Tue, 2008-08-19 at 16:22 +0800, Cedric Ho wrote:
[Lucene on SSD]
> However it's still not good enough for our particular case. So I
> wonder if there are any tips for optimizing lucene performance on
> SSDs.
What aspect of performance do you find lacking? Is it searching or
indexing? While we
Hi all,
We are testing Lucene with SSD. No doubt the performance is much
better than that of a normal hard disk.
However it's still not good enough for our particular case. So I
wonder if there are any tips for optimizing lucene performance on
SSDs.
For example, I saw that Lucene's BufferedIndex
Hi Nilesh,
I have a few queries regarding optimizing lucene for search performance.
1. We index around 50 million text documents with index size greater
than 40GB, and hence runtime performance is curcial. Our system has
only simple keyword queries. Each search returns an object of type
Hits whic
Hi all,
I have a few queries regarding optimizing lucene for search performance.
1. We index around 50 million text documents with index size greater
than 40GB, and hence runtime performance is curcial. Our system has
only simple keyword queries. Each search returns an object of type
Hits which
13 matches
Mail list logo
