"Tony Qian" wrote on 19/04/2007:
> I found the problem which slowed down indexing. It is our NFS file
system.
If only the index is maintained on NFS (say input is on local disk or DB or
such) it may help to index to local disk and only occasionally (once a
day?) copy/update to an index maintained
"Tony Qian" <[EMAIL PROTECTED]> wrote:
> I found the problem which slowed down indexing. It is our NFS file
> system.
NFS performance is generally slower than local filesystem, though
there may be ways to tune it (I'm not sure). I have heard but not
personally verified that mounting NFS read-onl
Doron and Erick,
I found the problem which slowed down indexing. It is our NFS file system.
Thanks for help.
Tony
From: "Tony Qian" <[EMAIL PROTECTED]>
Reply-To: java-user@lucene.apache.org
To: java-user@lucene.apache.org
Subject: Re: Index performance
Date: Mon, 16 Apr 200
Doron,
I'll try that and let you know the result.
thanks for suggestions.
Tony
From: Doron Cohen <[EMAIL PROTECTED]>
Reply-To: java-user@lucene.apache.org
To: java-user@lucene.apache.org
Subject: Re: Index performance
Date: Thu, 12 Apr 2007 13:40:07 -0700
To cover all possible n
Erick,
Sorry for late reply. I was stuck with other project. content object is
plain Java object. It has all fields set.
Thanks,
Tony
From: "Erick Erickson" <[EMAIL PROTECTED]>
Reply-To: java-user@lucene.apache.org
To: java-user@lucene.apache.org
Subject: Re: Index perfo
To cover all possible non-indexing overhead, better measure with something
like this:
static long indexContents(IndexWriter writer, List storyContentList)
throws IOException {
long res = 0;
if (storyContentList != null && storyContentList.size() != 0) {
try {
could that be where the time is
spent?
Erick
On 4/12/07, Tony Qian <[EMAIL PROTECTED]> wrote:
Otis,
I timed just for indexing.
thanks,
Tony
>From: Otis Gospodnetic <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: Re: Index performance
>D
> I tried to index it. It took from 7-10 seconds to index about 90
documents.
That would be around 10 documents per second - way too slow. A Lucene's
perf test adding 12,000 docs sized similar to your sample doc (1400
characters) on a not so strong machine shows much faster pace - 146 docs
per sec
Otis,
I timed just for indexing.
thanks,
Tony
From: Otis Gospodnetic <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Index performance
Date: Thu, 12 Apr 2007 09:31:49 -0700 (PDT)
Hi Tony,
Your code looks fine to me. I'm not sure what you timed
Eric,
Thanks for the information. The id is generated by database and it is
unique. So I only need to index it and don't need to store it, right
Tony
From: "Erick Erickson" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Index perf
Another question is if I can delete document based on storyIndentity field
(
using IndexReader.deleteDocuments(term)). Since storyIdentity field is not
indexed, is there any performance issue or I should index it too (and
store
it)?
As to your very last question, No, there'll be no performance
Hi Tony,
Your code looks fine to me. I'm not sure what you timed - the whole app run,
just indexing, indexing + optimizing... If you times indexing + optimizing,
leave optimization out of the timer. How long do you think this should take?
Try setting maxBufferedDocs to 90.
Otis
. . . . .
12 matches
Mail list logo