On Fri, Jan 9, 2009 at 12:18 AM, smock wrote:
> In some ways I have a 'small index' (~8 million documents at the moment).
> However, I have a lot of attributes (currently about 30, but I'm expecting
> that number to keep growing) and am interested in faceting across all of
> them for every search
On Jan 9, 2009, at 12:28 AM, smock wrote:
I'm using 1.3 - are the nightly builds stable enough to use in
production?
Testing always recommended, and no official guarantees are made of
course, but trunk is vastly superior to 1.3 in faceting performance.
I'd use trunk (in fact I am) in pro
should back up a bit and look at your requirements: both
>>> query latency and throughput.
>>> If the index is small enough, distributed search is definitely not the
>>> first step to take to address performance issues - there are many
>>> other things to look int
ing at what queries are slowest, and we may be able to
>> help speed them up through some optimizations.
>>
>> -Yonik
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Solr-on-a-multiprocessor-machine-tp21360747p21366406.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>
>
st, and we may be able to
> help speed them up through some optimizations.
>
> -Yonik
>
>
--
View this message in context:
http://www.nabble.com/Solr-on-a-multiprocessor-machine-tp21360747p21366406.html
Sent from the Solr - User mailing list archive at Nabble.com.
Maybe we should back up a bit and look at your requirements: both
query latency and throughput.
If the index is small enough, distributed search is definitely not the
first step to take to address performance issues - there are many
other things to look into first.
Start by looking at what queries
e must retrieve the top 10 documents
> from each shard - more work is done. Single request latency *can* be
> shorter under the right circumstances, but under load it will always
> lose since more work is done in aggregate.
>
> -Yonik
>
>
--
View this message in context:
http://www.nabble.com/Solr-on-a-multiprocessor-machine-tp21360747p21365956.html
Sent from the Solr - User mailing list archive at Nabble.com.
On Thu, Jan 8, 2009 at 10:03 PM, smock wrote:
> I don't mean to be argumentative - just trying to understand, what is the
> difference between distributed search across processors, and distributed
> search across boxes (again, assuming that my searches are truly CPU bound)?
Even if your searches
#x27;d rather each
>>>> individual
>>>> search be faster, which is why I'm interested in distributing the
>>>> index
>>>> across my 8 procs.
>>>
>>> As Yonik mentioned, it depends greatly on the size of the index/RAM
>>> rati
procs.
>>
>> As Yonik mentioned, it depends greatly on the size of the index/RAM
>> ratio. I don't see any reason why, in theory, two Solrs in a single
>> Tomcat could not both work on a single query in parallel, but I've
>> never tried it. I _hav
n a single using
> a webapp container per Solr instance (in my case, Jetty).
>
> Note that if these instances are sharing a single disk, and your RAM
> is low, then they will be competing over the slowest resource on your
> machine and the query could be IO bound, in which case sharding is
> useless.
>
> -Mike
>
>
--
View this message in context:
http://www.nabble.com/Solr-on-a-multiprocessor-machine-tp21360747p21365126.html
Sent from the Solr - User mailing list archive at Nabble.com.
On 8-Jan-09, at 3:37 PM, smock wrote:
Assuming I have enough RAM then, should I be able to get a
performance boost
with my current setup? Basically, the question I am trying to
answer is -
will the Tomcat+Solr setup I have above utilize multiple processors
or do I
need to do something el
Solr will use multiple processors. Most of your speed will come from
cached responses. Use a single instance, test with real query logs,
and tune the cache sizes by looking at the cache hit statistics in
the statistics page of the Solr admin UI.
wunder
On 1/8/09 3:37 PM, "smock" wrote:
>
> Ass
use you have 2 JVMs
> eating up memory instead of one, further lowering the cache hit ratio
> of the OS disk cache.
>
> With a 2 CPU machine, a single Solr index is advisable, esp for web
> traffic where there will be plenty of requests to keep both CPUs busy.
>
> -Yonik
On Thu, Jan 8, 2009 at 4:51 PM, smock wrote:
> Thanks for the reply - could you please give me some more details on what
> you mean?
If there isn't enough memory to cache the index in RAM, then your
bottleneck could be from retrieving stored fields from disk.
Distributed search will make this muc
case with my prior
>> distributed search solution (using sphinx) in which I did see the
>> expected
>> performance boost.
>>
>> Thanks,
>> -Harish
>> --
>> View this message in context:
>> http://www.nabble.com/Solr-on-a-multiprocessor-ma
tion. Both indexes are being
> run off of the same disk, but this was also the case with my prior
> distributed search solution (using sphinx) in which I did see the expected
> performance boost.
>
> Thanks,
> -Harish
> --
> View this message in context:
> http://www.nabb
f the same disk, but this was also the case with my prior
distributed search solution (using sphinx) in which I did see the expected
performance boost.
Thanks,
-Harish
--
View this message in context:
http://www.nabble.com/Solr-on-a-multiprocessor-machine-tp21360747p21360747.html
Sent from the
18 matches
Mail list logo
