https://issues.apache.org/jira/browse/SOLR-5478
There it goes
On Mon, Nov 18, 2013 at 5:44 PM, Manuel Le Normand
manuel.lenorm...@gmail.com wrote:
Sure, I am out of office till end of week. I reply after i upload the patch
Manuel, that sounds very interesting. Would you be willing to
contribute this back to the community?
On Mon, Nov 18, 2013 at 9:53 AM, Manuel Le Normand
manuel.lenorm...@gmail.com wrote:
In order to accelerate the BinaryResponseWriter.write we extended this
writer class to implement the docid to
Hi
Thanks very much for your answers :)
Manuel, if you have a patch I will be glad to test it's performance
Yuval
On Mon, Nov 18, 2013 at 10:49 AM, Shalin Shekhar Mangar
shalinman...@gmail.com wrote:
Manuel, that sounds very interesting. Would you be willing to
contribute this back to the
Sure, I am out of office till end of week. I reply after i upload the patch
.
-Original Message-
From: Erick Erickson [mailto:erickerick...@gmail.com]
Sent: Wednesday, October 30, 2013 3:17 AM
To: solr-user@lucene.apache.org
Subject: Re: distributed search is significantly slower than direct
search
You can't. There will inevitably be some overhead
: Thursday, November 14, 2013 1:30 AM
To: solr-user@lucene.apache.org
Subject: Re: distributed search is significantly slower than direct
search
It's surprising such a query takes a long time, I would assume that
after
trying consistently q=*:* you should be getting cache hits and times
should
[mailto:idokis...@gmail.com] On Behalf Of
Manuel Le Normand
Sent: Thursday, November 14, 2013 1:30 AM
To: solr-user@lucene.apache.org
Subject: Re: distributed search is significantly slower than direct
search
It's surprising such a query takes a long time, I would assume
)?
-Original Message-
From: idokis...@gmail.com [mailto:idokis...@gmail.com] On Behalf Of
Manuel Le Normand
Sent: Thursday, November 14, 2013 1:30 AM
To: solr-user@lucene.apache.org
Subject: Re: distributed search is significantly slower than direct
search
It's surprising such a query takes
In order to accelerate the BinaryResponseWriter.write we extended this
writer class to implement the docid to id tranformation by docValues (on
memory) with no need to access stored field for id reading nor lazy loading
of fields that also has a cost. That should improve read rate as docValues
are
@lucene.apache.org
Subject: Re: distributed search is significantly slower than direct search
It's surprising such a query takes a long time, I would assume that after
trying consistently q=*:* you should be getting cache hits and times should be
faster. Try see in the adminUI how do your query/doc
, configuration, query)?
-Original Message-
From: idokis...@gmail.com [mailto:idokis...@gmail.com] On Behalf Of Manuel Le
Normand
Sent: Thursday, November 14, 2013 1:30 AM
To: solr-user@lucene.apache.org
Subject: Re: distributed search is significantly slower than direct search
It's surprising
: Wednesday, October 30, 2013 3:17 AM
To: solr-user@lucene.apache.org
Subject: Re: distributed search is significantly slower than direct search
You can't. There will inevitably be some overhead in the distributed case.
That said, 7 seconds is quite long.
5,000 rows is excessive, and probably where
]
Sent: Wednesday, October 30, 2013 3:17 AM
To: solr-user@lucene.apache.org
Subject: Re: distributed search is significantly slower than direct
search
You can't. There will inevitably be some overhead in the distributed
case.
That said, 7 seconds is quite long.
5,000 rows is excessive
: Erick Erickson [mailto:erickerick...@gmail.com]
Sent: Wednesday, October 30, 2013 3:17 AM
To: solr-user@lucene.apache.org
Subject: Re: distributed search is significantly slower than direct search
You can't. There will inevitably be some overhead in the distributed case. That
said, 7 seconds is quite
Hi all,
I am using Solr 4.4 with multi cores. One core (called template) is my
routing core.
When I run
http://127.0.0.1:8983/solr/template/select?rows=5000q=*:*shards=127.0.0.1:8983/solr/core1,
it consistently takes about 7s.
When I run http://127.0.0.1:8983/solr/core1/select?rows=5000q=*:*,
You can't. There will inevitably be some overhead in the
distributed case. That said, 7 seconds is quite long.
5,000 rows is excessive, and probably where your issue is. You're
having to go out and fetch the docs across the wire. Perhaps there
is some batching that could be done there, I don't
16 matches
Mail list logo
