[
https://issues.apache.org/jira/browse/LUCENE-3653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13172303#comment-13172303
]
Gerrit Jansen van Vuuren commented on LUCENE-3653:
--------------------------------------------------
this is not a problem if your ok with 200 or less requests on a server and your
search time can be 0.5 or more seconds. But if your whole execution window is
measured in milliseconds and you get 7000-10000 requests per second on a server
then yes it does matter.
If that method is called in each thread that is trying to search on the index
then it becomes a point of contention, if there are several synchronized
separately synchronized methods it only becomes worse. Your basically saying
its ok for all threads to wait sequentially in several areas of the code during
an in memory readonly index search.
> Lucene Search not scalling
> --------------------------
>
> Key: LUCENE-3653
> URL: https://issues.apache.org/jira/browse/LUCENE-3653
> Project: Lucene - Java
> Issue Type: Improvement
> Reporter: Gerrit Jansen van Vuuren
> Attachments: App.java,
> LUCENE-3653-VirtualMethod+AttributeSource.patch,
> LUCENE-3653-VirtualMethod+AttributeSource.patch,
> LUCENE-3653-VirtualMethod+AttributeSource.patch, LUCENE-3653-no-sync.png,
> LUCENE-3653-sync-.png, LUCENE-3653.patch,
> LUCENE-3653.patch-BiasedLockingStartupDelay_1.png,
> LUCENE-3653.patch-BiasedLockingStartupDelay_2.png,
> LUCENE-3653.patch-BiasedLockingStartupDelay_3.png,
> Threads-LUCENE-3653.patch.png, lucene-unsync.diff, profile_1_a.png,
> profile_1_b.png, profile_1_c.png, profile_1_d.png, profile_2_a.png,
> profile_2_b.png, profile_2_c.png
>
>
> I've noticed that when doing thousands of searches in a single thread the
> average time is quite low i.e. a few milliseconds. When adding more
> concurrent searches doing exactly the same search the average time increases
> drastically.
> I've profiled the search classes and found that the whole of lucene blocks on
> org.apache.lucene.index.SegmentCoreReaders.getTermsReader
> org.apache.lucene.util.VirtualMethod
> public synchronized int getImplementationDistance
> org.apache.lucene.util.AttributeSourcew.getAttributeInterfaces
> These cause search times to increase from a few milliseconds to up to 2
> seconds when doing 500 concurrent searches on the same in memory index. Note:
> That the index is not being updates at all, so not refresh methods are called
> at any stage.
> Some questions:
> Why do we need synchronization here?
> There must be a non-lockable solution for these, they basically cause
> lucene to be ok for single thread applications but disastrous for any
> concurrent implementation.
> I'll do some experiments by removing the synchronization from the methods of
> these classes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
