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
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
----- Original Message ----
> From: Ziqi Zhang <[EMAIL PROTECTED]>
> To: solr-user@lucene.apache.org
> Sent: Wednesday, February 6, 2008 6:37:40 PM
> Subject: Re: how to improve concurrent request performance and stress testing
>
> Thanks
>
Yonik,
>
>
> >
>
It
>
uses
>
a
>
thread
>
per
>
request,
>
simultaneously
>
(up
>
to
>
any
>
limit
> >
>
configured
>
by
>
the
>
app
>
server)
>
> How
>
can
>
I
>
change
>
this
>
setting
>
then?
>
I
>
suppose
>
it
>
is
>
to
>
do
>
with
>
Jetty
>
or
> Tomcat
>
whichever
>
hosts
>
solr
>
application,
>
not
>
through
>
the
>
solrconfig?
>
> I
>
still
>
do
>
not
>
understand
>
why
>
sending
>
100
>
request
>
(of
>
same
>
query)
>
from
>
100
> threads
>
throws
>
solr
>
server
>
to
>
silence
>
-
>
is
>
it
>
because
>
of
>
the
>
computational
> cost
>
to
>
deal
>
with
>
same
>
query
>
in
>
100
>
separate
>
threads?
>
> I
>
noticed
>
that
>
disabling
>
facet
>
counts
>
improves
>
things
>
a
>
bit,
>
but
>
not
> significant.
>
> Thanks
>
in
>
advance!
>
>
