[
https://issues.apache.org/jira/browse/LUCENE-2143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788883#action_12788883
]
Michael McCandless commented on LUCENE-2143:
--------------------------------------------
bq. So why also, are you only picking one indexing rate? Should you not also be
varying this from low, all the way up to saturating the system with maximum
indexing rate, to properly stress the system?
Yes, you're right -- we need to see the full curve in general, when
testing NRT. I already did that in LUCENE-2061 (see the first 3
tables), testing saturated QPS at 1/10/100/1000 DPS, and reopen rate
of every 0.1/1.0/5.0/10.0/30.0 seconds, and update vs add case.
It's a 4d space that NRT tests should cover -- freshness, QPS, DPS,
add vs update; you fix 3 of them and saturate the other, to get the
curve. The big question is how much you have to pay (lower QPS/DPS)
for different levels of freshness.
What was good about the tests in LUCENE-2061 is, as long as you flush
once per second, you don't pay much for freshness, even down to 10X
reopens per second, at least at the 100 docs/sec indexing rate. I
think for most NRT apps, 100 msec freshness is more than enough.
I'm focused on the 100 docs/sec indexing rate, for this issue, because
that's able to reproduce this odd problem (though I imagine other
DPS would as well).
> Understand why NRT performance is affected by flush frequency
> -------------------------------------------------------------
>
> Key: LUCENE-2143
> URL: https://issues.apache.org/jira/browse/LUCENE-2143
> Project: Lucene - Java
> Issue Type: Bug
> Components: Index
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 3.1
>
>
> In LUCENE-2061 (perf tests for NRT), I test NRT performance by first
> getting a baseline QPS with only searching, using enough threads to
> saturate.
> Then, I pick an indexing rate (I used 100 docs/sec), and index docs at
> that rate, and I also reopen a NRT reader at different frequencies
> (10/sec, 1/sec, every 5 seconds, etc.), and then again test QPS
> (saturated).
> I think this is a good approach for testing NRT -- apps can see, as a
> function of "freshness" and at a fixed indexing rate, what the cost is
> to QPS. You'd expect as index rate goes up, and freshness goes up,
> QPS will go down.
> But I found something very strange: the low frequency reopen rates
> often caused a highish hit to QPS. When I forced IW to flush every
> 100 docs (= once per second), the performance was generally much
> better.
> I actually would've expected the reverse -- flushing in batch ought to
> use fewer resoruces.
> One theory is something odd about my test env (based on OpenSolaris),
> so I'd like to retest on a more mainstream OS.
> I'm opening this issue to get to the bottom of it...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
