Right, the point of the newSearcher and firstSearcher events
is to smooth out spikes in response time, and it looks like
that's happening now.
>From here, you're in to query tuning. Without knowing your queries,
your schema, how many docs on a server, memory allocation
and all that it's impossibl
Thanks Erick, this listener doing quite a good job. But not what I needed.
Do the solr has any other things that I can look into to make it faster.
FYI speed goes to 1 sec to 1.2 sec. I actually needed around 500 ms.
On Tue, 5 Jan 2016 at 18:24 Erick Erickson wrote:
> Yep. Do note what's happe
Yep. Do note what's happening here. You're executing a query
that potentially takes 10 seconds to execute (based on your
earlier post). But you may be opening a new searcher every
2 seconds. You may start to see "too many on deck searchers"
in your log. If you do do _not_ try to "fix" this by uppin
If I'm correct, you are talking about this
*or may be here too.*
static firstSearcher warming in
solrconfig.xml
Thanks,
Novin
On Tue, 5 Jan 201
It sounds like you're not doing proper autowarming,
which you'd need to do either with hard or
soft commits that open new searchers.
see: https://wiki.apache.org/solr/SolrCaching#Cache_Warming_and_Autowarming
In particular, you should have a newSearcher event
that facets on the fields you expect
Thanks David. It is quite good to use for NRT.
Apologies, I didn't mention that facet search is really slow.
I found the below reason which could be the reason because I am using facet
spatial search which is getting slow.
To know more about solr hard and soft commits, have a look at this blog :
You should use solr softcommit for this use case. So, by setting softcommit
to 5 seconds and autoCommit to minute with openSearcher=false should do the
work.
6
false
2000
Reference link-
https://cwiki.apache.org/confluence/display/solr/Near+Real+Time+Searching
To know more about solr
Hi guys,
I'm having trouble to figure what would be idle solr config for where:
I'm doing hard commit in every minute for very few number of users
because I have to show those docs in search results quickly when user save
the changes.
It is causing the response in around 2 secs to show even I