Uwe Schindler wrote:
That lock contention is fine there as this is the central point where all IO
is done. This does not mean that only one query is running in parallel, the
queries are still running in parallel. But there is one place where all IO
is waiting for one file descriptor. This is not different with multiple
IndexSearchers. YourKit simply shows this place as it has most contention.
You are using Windows? On Linux it should use NIO automatically
(FSDir.open() uses platform specific defaults). You can also improve speed
and play with e.g. MMapDirectory on 64 bit platforms. Or try out how NIO
works on your platform.
Im using Windows and I'll try NIO, good idea, my app is already memory
hungry in other areas so I guess MMapped is a no go, doe sit use heap or
perm memory ?
I understand the lock on I/O point but what was concerning me is in the
thread view the threads were blocking for some time, not just a couple
of milliseconds. I actually refactored my code to make it multithreaded
specifically tfor his bit of code becaue alot of searches was necessary,
and the elapsed time is faster than using a single thread but not as
fast as Id hoped.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
