[
https://issues.apache.org/jira/browse/LUCENE-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615727#action_12615727
]
Michael McCandless commented on LUCENE-753:
-------------------------------------------
OK I ran the uncached test, using the Search task. JRE & hardware are
the same as above.
I generated a larger (6150) set of queries to make sure the threads
never wrap around and do the same queries again. I also run only 1
round for the same reason. Between tests I evict the OS's IO cache.
||Number of Threads||Patch rec/s||Trunk rec/s||Pctg gain||
|2|32.2|23.8|35.3%|
|4|16.4|12.7|29.1%|
|8|8.5|3.5|142.9%|
|16|3.8|2.7|40.7%|
The gains are better. The 8 thread case I don't get; I re-ran it and
it still came out much better (135.7%). It could be 8 threads is the
sweet spot for concurrency on this hardware.
> Use NIO positional read to avoid synchronization in FSIndexInput
> ----------------------------------------------------------------
>
> Key: LUCENE-753
> URL: https://issues.apache.org/jira/browse/LUCENE-753
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Store
> Reporter: Yonik Seeley
> Attachments: FileReadTest.java, FileReadTest.java, FileReadTest.java,
> FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java,
> FSDirectoryPool.patch, FSIndexInput.patch, FSIndexInput.patch,
> lucene-753.patch, lucene-753.patch
>
>
> As suggested by Doug, we could use NIO pread to avoid synchronization on the
> underlying file.
> This could mitigate any MT performance drop caused by reducing the number of
> files in the index format.
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
