I already had the chance to setup a new server for testing. Before deploying
my application I checked my solrconfig against the solrconfig from 1.3. And
removed the deprecated parameters. I started updating the new index. I
ingest 100 documents att a time and then I do a commit(). With 2000 ingested
documents the commit time is 1-3 seconds. I'll get back tomorrow with more
results.
Uwe
On Sun, Oct 5, 2008 at 2:52 PM, Uwe Klosa <[EMAIL PROTECTED]> wrote:
> It's a live server with many search queries. I will set up a test server
> next week or the week after and index the same amount of documents. I will
> get back with the results.
>
> Uwe
>
>
> On Sat, Oct 4, 2008 at 8:18 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
>
>> On Sat, Oct 4, 2008 at 11:55 AM, Uwe Klosa <[EMAIL PROTECTED]> wrote:
>> > A "Opening Server" is always happening directly after "start commit"
>> with no
>> > delay.
>>
>> Ah, so it doesn't look like it's the close of the IndexWriter then!
>> When do you see the "end_commit_flush"?
>> Could you post everything in your log between when the commit begins
>> and when it ends?
>> Is this a live server (is query traffic continuing to come in while
>> the commit is happening?) If so, it would be interesting to see (and
>> easier to debug) if it happened on a server with no query traffic.
>>
>> > But I can see many {commit=} with QTime around 280.000 (4 and a half
>> > minutes)
>>
>> > One difference I could see to your logging is that I have
>> waitFlush=true.
>> > Could that have this impact?
>>
>> These parameters (waitFlush/waitSearcher) won't affect how long it
>> takes to get the new searcher registered, but does affect at what
>> point control is returned to the caller (and hence when you see the
>> response). If waitSearcher==false, then you see the response before
>> searcher warming, otherwise it blocks until after. waitFlush==false
>> is not currently supported (it will always act as true), so your
>> change of that doesn't matter.
>>
>> -Yonik
>>
>
>
