Thanks to Ryan Ernst, my issue is duplicate of SOLR-4449.
I think that this proposal might be very useful (some supporting links are
attached there. worth reading..)
On Tue, Jul 30, 2013 at 11:49 PM, Isaac Hebsh isaac.he...@gmail.com wrote:
Hi,
I submitted a new JIRA for this:
You'd probably start in CloudSolrServer in SolrJ code,
as far as I know that's where the request is sent out.
I'd think that would be better than changing Solr itself
since if you found that this was useful you wouldn't
be patching your Solr release, just keeping your client
up to date.
Best
This has been suggested, but so far it's not been implemented
as far as I know.
I'm curious though, how many shards are you dealing with? I
wonder if it would be a better idea to try to figure out _why_
you so often have a slow shard and whether the problem could
be cured with, say, better
Hi Erick, thanks.
I have about 40 shards. repFactor=2.
The cause of slower shards is very interesting, and this is the main
approach we took.
Note that in every query, it is another shard which is the slowest. In 20%
of the queries, the slowest shard takes about 4 times more than the average
On 7/27/2013 3:33 PM, Isaac Hebsh wrote:
I have about 40 shards. repFactor=2.
The cause of slower shards is very interesting, and this is the main
approach we took.
Note that in every query, it is another shard which is the slowest. In 20%
of the queries, the slowest shard takes about 4 times
Shawn, thank you for the tips.
I know the significant cons of virtualization, but I don't want to move
this thread into a virtualization pros/cons in the Solr(Cloud) case.
I've just asked what is the minimal code change should be made, in order to
examine whether this is a possible solution or
Hi!
When SolrClound executes a query, it creates shard requests, which is sent
to one replica of each shard. Total QTime is determined by the slowest
shard response (plus some extra time). [For simplicity, let's assume that
no stored fields are requested.]
I suffer from a situation where in
