lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anatoli Matuskova <anatoli.matusk...@gmail.com>
Subject performance on concurrent search request
Date Tue, 02 Apr 2013 14:15:55 GMT
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.

Mime
View raw message