In this thread about performance on concurrent search requests, Otis said:
http://lucene.472066.n3.nabble.com/how-to-improve-concurrent-request-performance-and-stress-testing-td496411.html
/Imagine this type of code:
synchronized (someGlobalObject) {
// search
}
What happens when 100 threads his this spot? The first one to get there
gets in and runs the search and 99 of them wait.
What happens if that "// search" also involves expensive operations, lots
of IO, warming up, cache population, etc? Those 99 threads will have to
wait a while.... :)
That's why it is recommended to warm up the searcher ahead of time before
exposing it to real requests. However, even if you warm things up, that
sync block will remain there, and at some point this will become a
bottleneck. What that point is depends on the hardware, index size, query
complexity and rat, even JVM.
Otis /
I'm wondering if this synchronized is still an issue in Solr 4.x? Is it
because how Solr deals with the index searcher or is it because how it is
implemented in Lucene?
--
View this message in context:
http://lucene.472066.n3.nabble.com/performance-on-concurrent-search-request-tp4053182.html
Sent from the Solr - User mailing list archive at Nabble.com.
