lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] Commented: (LUCENE-2061) Create benchmark & approach for testing Lucene's near real-time performance
Date Mon, 16 Nov 2009 14:05:39 GMT


Michael McCandless commented on LUCENE-2061:

OK the last test had a silly bug, that made update QPS slowdown even @ low indexing &
reopen rates look worse than it should be...

The test ran on a fully optimized index, ie, it had no deletions.

So the pure searching & add tests had no deletedDocs vector to check, but the update test,
after the very first doc was indexed, had to check the deleteDocs.  So, really, that 20% slowdown
we see right off the bat for the updates case is the added cost of having to check the BitVector.

So the test was unfair.  I'll re-run after deleting one doc from the base index...

> Create benchmark & approach for testing Lucene's near real-time performance
> ---------------------------------------------------------------------------
>                 Key: LUCENE-2061
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Task
>          Components: Index
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>            Priority: Minor
>         Attachments: LUCENE-2061.patch, LUCENE-2061.patch
> With the improvements to contrib/benchmark in LUCENE-2050, it's now
> possible to create compelling algs to test indexing & searching
> throughput against a periodically reopened near-real-time reader from
> the IndexWriter.
> Coming out of the discussions in LUCENE-1526, I think to properly
> characterize NRT, we should measure net search throughput as a
> function of both reopen rate (ie how often you get a new NRT reader
> from the writer) and indexing rate.  We should also separately measure
> pure adds vs updates (deletes + adds); the latter is much more work
> for Lucene.
> This can help apps make capacity decisions... and can help us test
> performance of pending improvements for NRT (eg LUCENE-1313,
> LUCENE-2047).

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:
For additional commands, e-mail:

View raw message