Hi,
I am using timeAllowed and a collection with shards.
Docs list contains results only if QTime(query time) < timeAllowed.
In other cases (partialResults=true in responseHeader) docs are empty.
/solr/collection_with_shards/select?etimeAllowed=1000&q=some_slow_query
docs is empty
If access a spe
TimeAllowed stops looking when the timer expires. If it hasn’t found any docs
with a
non-zero score by then, you’ll get zero hits.
It has to be this way, because Solr doesn’t know whether a doc is a hit until
Solr scores it.
So this is normal behavior, assuming that some part of the processing
Thanks Colvin!
All the responses were helpful.
Best
Mark
On Wed, Sep 16, 2020 at 4:06 AM Colvin Cowie
wrote:
> Hi Mark,
>
> If queries taking 10 (or however many) seconds isn't acceptable, then
> either you need to a) prevent or optimize those queries, b) improve the
> performance of your index
Thanks much Bram!
Best,
Mark
On Wed, Sep 16, 2020 at 3:59 AM Bram Van Dam wrote:
> There are a couple of open issues related to the timeAllowed parameter.
> For instance it currently doesn't work on conjunction with the
> cursorMark parameter [1]. And on Solr 7 it doesn't work at all [2].
>
> B
Hi Mark,
If queries taking 10 (or however many) seconds isn't acceptable, then
either you need to a) prevent or optimize those queries, b) improve the
performance of your index, c) use timeAllowed and accept that queries
taking that long may fail or provide incomplete results, or d) a
combination
There are a couple of open issues related to the timeAllowed parameter.
For instance it currently doesn't work on conjunction with the
cursorMark parameter [1]. And on Solr 7 it doesn't work at all [2].
But other than that, when users have a lot of query flexibility, it's a
pretty good idea to lim
Thanks Dominique!
So is this parameter generally recommended or not. I wanted to try with a
value of 10s. We are not using it now.
My goal is to prevent a query from running more than 10s on the solr server
and choking it.
What is the general recommendation.
Thanks!
Mark
On Tue, Sep 15, 2020 at
Hi,
1. Yes, your analysis is correct
2. Yes, it can occurs too with very slow query.
Regards
Dominique
Le mar. 15 sept. 2020 à 15:14, Mark Robinson a
écrit :
> Hi,
>
> When in a sample query I used "timeAllowed" as low as 10mS, I got value for
>
> "numFound" as say 2000, but no docs were ret
We use it on all requests. We are running 4.10.4 for most searches.
We set a pretty high timeAllowed, either five or thirty seconds, depending on
the service.
wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/ (my blog)
> On Nov 30, 2016, at 6:28 PM, William Bell wr
Sorry for that. i could not share direct query. response header is
"QTime":5536,
"params":{
"hl.fragsize":"50",
"indent":"true",
"hl.simple.pre":"",
"collection":"case-collection_2011",
"hl.fl":"*",
"wt":"json",
"hl":"true",
"rows":"10",
"d
The screenshots didn't come through. Can you paste text into email? The
query URL is the most important thing.
Thx
On Fri, 11 Mar 2016, at 02:00 PM, Anil wrote:
> HI Upayavira,
>
> Thanks for your response. Following are the screenshots of the same
> query with and without partial results in
HI Upayavira,
Thanks for your response. Following are the screenshots of the same query
with and without partial results in the response.
Please let me know if you have any questions.
[image: Inline images 1]
[image: Inline images 2]
Regards,
Anil
On 11 March 2016 at 19:13, Upayavira wrote:
Show us the query URL. It would seem like your timeallowed isn't taking
effect.
Upayavira
On Fri, 11 Mar 2016, at 12:48 PM, Anil wrote:
> Thank you.
>
> in my test, i have timeallowed 10 ms. response has no partial results (no
> partial flag in the response header) and Qtime is 200 ms. so little
Thank you.
in my test, i have timeallowed 10 ms. response has no partial results (no
partial flag in the response header) and Qtime is 200 ms. so little
confused.
On 11 March 2016 at 18:07, Upayavira wrote:
>
>
> On Fri, 11 Mar 2016, at 07:22 AM, Anil wrote:
> > HI,
> >
> > is timeallowed is m
On Fri, 11 Mar 2016, at 07:22 AM, Anil wrote:
> HI,
>
> is timeallowed is max threshold of Qtime ? or overall time ? Please
> clarify.
I do not understand the difference.
Basically, when a query is happening, a collector gathers matching
documents. The timeallowed parameter sets a point at whi
Apologies for late reply, Thanks Toke for a great explaination :)
I am new in solr so i am unaware of DocValues, so please can you explain.
With Regards
Aman Tandon
On Fri, May 2, 2014 at 1:52 PM, Toke Eskildsen wrote:
> On Thu, 2014-05-01 at 23:03 +0200, Aman Tandon wrote:
> > So can you expla
On Thu, 2014-05-01 at 23:03 +0200, Aman Tandon wrote:
> So can you explain how enum is faster than default.
The fundamental difference is than enum iterates terms and counts how
many of the documents associated to the terms are in the hits, while fc
iterates all hits and updates a counter for the
On Thu, 2014-05-01 at 23:38 +0200, Shawn Heisey wrote:
> I was surprised to read that fc uses less memory.
I think that is an error in the documentation. Except for special cases,
such as asking for all facet values on a high cardinality field, I would
estimate that enum uses less memory than fc.
On 5/1/2014 3:03 PM, Aman Tandon wrote:
> Please check that link
> http://wiki.apache.org/solr/SimpleFacetParameters#facet.method there is
> something mentioned in facet.method wiki
>
> *The default value is fc (except for BoolField which uses enum) since it
> tends to use less memory and is faster
Hi Shawn,
Please check that link
http://wiki.apache.org/solr/SimpleFacetParameters#facet.method there is
something mentioned in facet.method wiki
*The default value is fc (except for BoolField which uses enum) since it
tends to use less memory and is faster then the enumeration method when a
fiel
On 4/30/2014 5:53 PM, Aman Tandon wrote:
> Shawn -> Yes we have some plans to move to SolrCloud, Our total index size
> is 40GB with 11M of Docs, Available RAM 32GB, Allowed heap space for solr
> is 14GB, the GC tuning parameters using in our server
> is -XX:+UseConcMarkSweepGC -XX:+PrintGCApplicat
Jeff -> Thanks Jeff this discussion on jira is really quite helpful. Thanks
for this.
Shawn -> Yes we have some plans to move to SolrCloud, Our total index size
is 40GB with 11M of Docs, Available RAM 32GB, Allowed heap space for solr
is 14GB, the GC tuning parameters using in our server
is -XX:+U
It¹s not just FacetComponent, here¹s the original feature ticket for
timeAllowed:
https://issues.apache.org/jira/browse/SOLR-502
As I read it, timeAllowed only limits the time spent actually getting
documents, not the time spent figuring out what data to get or how. I
think that means the primar
On 4/29/2014 11:43 PM, Aman Tandon wrote:
> My heap size is 14GB and i am not using solr cloud currently, 40GB index
> is replicated from master to two slaves.
>
> I read somewhere that it return the partial results which is computed by
> the query in that specified amount of time which is define
On Wed, Apr 30, 2014 at 2:16 PM, Aman Tandon wrote:
> name="time">3337.0
> 6739.0
>
Most time is spent in facet counting. FacetComponent doesn't checks
timeAllowed right now. You can try to experiment with facet.method=enum or
even with https://issues.apache.org/jira/b
Hi Salman,
here is the my debug query dump please help!. I am unable to find the
wildcards in it.
true 0 10080 884159 629472 491426 259356
259029 257193 195077
193569 179369 115356
111644 86794 80621 72815 68982
65082
I had this issue too. timeAllowed only works for a certain phase of the
query. I think that's the 'process' part. However, if the query is taking
time in 'prepare' phase (e.g. I think for wildcards to get all the possible
combinations before running the query) it won't have any impact on that.
You
Shawn this is the first time i raised this problem.
My heap size is 14GB and i am not using solr cloud currently, 40GB index
is replicated from master to two slaves.
I read somewhere that it return the partial results which is computed by
the query in that specified amount of time which is defin
On 4/29/2014 10:05 PM, Aman Tandon wrote:
> I am using solr 4.2 with the index size of 40GB, while querying to my index
> there are some queries which is taking the significant amount of time of
> about 22 seconds *in the case of minmatch of 50%*. So i added a parameter
> timeAllowed = 2000 in my q
I'm not even sure what this is intended to produce. All documents with
terms two or more characters long? What use-case is this intended to
solve?
Because unless there's a _really_ good reason to do this, I'd just
dis-allow pure-wildcard queries on the app end.
This seems like an "XY" question. P
Unfortunately the timeAllowed parameter doesn't apply to the part of the
processing that makes wildcard queries so slow. It only applies to a later part
of the processing when the matching documents are being collected. There's some
discussion in the original ticket that implemented this
(https
Please file a JIRA. And a patch if you are so inclined.
On Fri, Jun 8, 2012 at 4:55 AM, Michael Kuhlmann wrote:
> Am 08.06.2012 11:55, schrieb Laurent Vaills:
>
>> Hi Michael,
>>
>> Thanks for the details that helped me to take a deeper look in the source
>> code. I noticed that each time a TimeE
Am 08.06.2012 11:55, schrieb Laurent Vaills:
Hi Michael,
Thanks for the details that helped me to take a deeper look in the source
code. I noticed that each time a TimeExceededException is caught the method
setPartialResults(true) is called...which seems to be what I'm looking for.
I have to i
Hi Michael,
Thanks for the details that helped me to take a deeper look in the source
code. I noticed that each time a TimeExceededException is caught the method
setPartialResults(true) is called...which seems to be what I'm looking for.
I have to investigate, since this partialResults does not s
Hi Laurent,
alas there is currently no such option. The time limit is handled by an
internal TimeLimitingCollector, which is used inside SolrIndexSearcher.
Since the using method only returns the DocList and doesn't have access
to the QueryResult, it won't be easy to return this information in
Are you requesting a large number of rows? If so, request smaller chunks, like
ten at a time. Then you can show those with a "waiting" note.
wunder
On Jun 7, 2012, at 1:14 PM, Laurent Vaills wrote:
> Hi everyone,
>
> We have some grouping queries that are quite long to execute. Some are too
>
36 matches
Mail list logo
