Thanks for the reply. > Executing an identical query again will likely satisfy the query from Solr's > caches. Solr won't need to talk to the actual index, and it will be REALLY > fast. Even a massively complex query, if it is cached, will be fast.
All caches are disabled in our schema file because of our indexing and searching ratio is high in our live environment. Sent from Outlook<http://aka.ms/weboutlook> ________________________________ From: Shawn Heisey <apa...@elyograg.org> Sent: Friday, May 10, 2019 9:32 PM To: solr-user@lucene.apache.org Subject: Re: Solr query takes a too much time in Solr 6.1.0 On 5/10/2019 7:32 AM, vishal patel wrote: > We have 2 shards and 2 replicas in Live environment. we have multiple > collections. > Some times some query takes much time(QTime=52552). There are so many > documents indexing and searching within milliseconds. There could be any number of causes of slow performance. A common reason is not having enough spare memory in the machine to allow the operating system to cache the index data. This is memory NOT allocated by programs (including Solr). Another common reason is that the heap size is too small, which causes Java to frequently perform full garbage collections, which will REALLY kill performance. Since there's very little information here, it's difficult for us to diagnose the cause. Here's a wiki page about performance problems: https://wiki.apache.org/solr/SolrPerformanceProblems (Disclaimer: I am the principal author of that page) > When we executed the same query again using admin panel, it does not take a > much time and it completes within 20 milliseconds. Executing an identical query again will likely satisfy the query from Solr's caches. Solr won't need to talk to the actual index, and it will be REALLY fast. Even a massively complex query, if it is cached, will be fast. Running the information from your logs through a URL decoder, this is what I found: q=+project_id:(2102117)+recipient_id:(4642365) +entity_type:(1) -action_id:(20 32) +action_status:(0) +is_active:(true) +(is_formtype_active:true) +(appType:1) If all of those fields are indexed, then I would not expect a properly sized server to be slow. If any of those fields are indexed=false and have docValues, then it could be a schema configuration issue. Searching docValues does work, but it's really slow. Your query does have an empty fq ... "fq=" ... I do not know whether that's problematic. Try it without that to verify. I would not expect it to cause problems, but I can't be sure. Thanks, Shawn
