I'd guess that what's happening is that you're pegging the CPU with 4 threads, serving up the absolute maximum that the machine will handle. The thing to look at is the throughput rather than avg response time (although that's going down but not as rapidly, which is still a bit puzzling).
Usually, adding more threads can increase throughput by allowing threads to steal some cycles while other threads block on, say, I/O. But if the CPU utilization is 100% adding more threads will not increase throughput, they just wait for each other. So your average response time includes the time threads are waiting, the context switching that Grijesh spoke of. So look at your machine with a performance monitor and see if your CPU is pegged. Or, more accurately, whether your CPU is pegged when 4 threads are active. Best Erick On Fri, Apr 29, 2011 at 7:43 AM, Marc Sturlese <marc.sturl...@gmail.com> wrote: > That's true. But the degradation is so big. If you use lunch concurrent > requests to a web app taht doesn't use Solr the time per request won't > degradate that much. For me, it looks more like a synchronized is happening > somewhere in Solr or Lucene and is causing this.-- > View this message in context: > http://lucene.472066.n3.nabble.com/Strange-performance-behaviour-when-concurrent-requests-are-done-tp505478p2878856.html > Sent from the Solr - User mailing list archive at Nabble.com. >
