Hi,
Usually, limit=-1 works as a single pass-through and counts accumulating;
but when limit >0 causes collecting per value docset, whic might take
longer. There's a note about this effect in uniqueBlock() description.
On Wed, Jul 8, 2020 at 11:29 AM ana wrote:
> Hi Team,
> Which is more optimiz
Yeah, for network latency I would recommend a tool like charlesproxy.
Edward
Em qui, 11 de jul de 2019 20:59, Erick Erickson
escreveu:
> true, although there’s still network that can’t be included.
>
> > On Jul 11, 2019, at 5:55 PM, Edward Ribeiro
> wrote:
> >
> > Wouldn't be the case of using
true, although there’s still network that can’t be included.
> On Jul 11, 2019, at 5:55 PM, Edward Ribeiro wrote:
>
> Wouldn't be the case of using &rows=0 parameter on those requests? Wdyt?
>
> Edward
>
> Em qui, 11 de jul de 2019 14:24, Erick Erickson
> escreveu:
>
>> Not only does Qtime n
Wouldn't be the case of using &rows=0 parameter on those requests? Wdyt?
Edward
Em qui, 11 de jul de 2019 14:24, Erick Erickson
escreveu:
> Not only does Qtime not include network latency, it also doesn't include
> the time it takes to assemble the docs for return, which can be lengthy
> when r
Not only does Qtime not include network latency, it also doesn't include
the time it takes to assemble the docs for return, which can be lengthy
when rows is large..
On Wed, Jul 10, 2019, 14:39 Shawn Heisey wrote:
> On 7/10/2019 3:17 PM, Lucky Sharma wrote:
> > I am seeing one very weird behavio
On 7/10/2019 3:17 PM, Lucky Sharma wrote:
I am seeing one very weird behaviour of QTime of SOLR.
Scenario is :
When I am hitting the Solr Cloud Instance, situated at a DC with my local
machine while load test I was seeing 400ms Qtime response and 1sec Http
Response time.
How much data was in t
And QTime doesn't include the time spent in the container (e.g., Tomcat or
Jetty) or network latency. Usually a query benchmark would be from the time
the client sent the query request until the time the client received the
query results.
The debug timing will help you understand which Solr co
On Thu, Feb 10, 2011 at 4:08 PM, Stijn Vanhoorelbeke
wrote:
> Hi,
>
> I've done some stress testing onto my solr system ( running in the ec2 cloud
> ).
> From what I've noticed during the tests, the QTime drops to just 1 or 2 ms (
> on a index of ~2 million documents ).
>
> My first thought pointe
Let's see what the queries are. If you're searching for single
terms that don't match many docs that's one thing. If you're looking
at many terms that match many documents, I'd expect larger numbers.
Unless you're hitting the document cache and not searching at all
Best
Erick
On Thu, Feb 10,
This is different for each model of computer. It has to do with
exactly what chips are used.
On Fri, Oct 23, 2009 at 10:42 AM, Jérôme Etévé wrote:
> 2009/10/23 Andrzej Bialecki :
>> Jérôme Etévé wrote:
>>>
>>> Hi all,
>>>
>>> I'm using Solr trunk from 2009-10-12 and I noticed that the QTime
>>>
2009/10/23 Andrzej Bialecki :
> Jérôme Etévé wrote:
>>
>> Hi all,
>>
>> I'm using Solr trunk from 2009-10-12 and I noticed that the QTime
>> result is always a multiple of roughly 50ms, regardless of the used
>> handler.
>>
>> For instance, for the update handler, I get :
>>
>> INFO: [idx1] webapp
Jérôme Etévé wrote:
Hi all,
I'm using Solr trunk from 2009-10-12 and I noticed that the QTime
result is always a multiple of roughly 50ms, regardless of the used
handler.
For instance, for the update handler, I get :
INFO: [idx1] webapp=/solr path=/update/ params={} status=0 QTime=0
INFO: [id
: The easiest way is to run maybe 100,000 or more queries and take an
: average. A single microsecond value for a query would be incredibly
: inaccurate.
that can be useful for doing the timing externally, if you're interested
in averaging over all X queries in a sequential batch, but it doesn't
The easiest way is to run maybe 100,000 or more queries and take an
average. A single microsecond value for a query would be incredibly
inaccurate.
-ToddFeak
-Original Message-
From: AHMET ARSLAN [mailto:iori...@yahoo.com]
Sent: Friday, January 23, 2009 1:33 AM
To: solr-user@lucene.apa
On Oct 11, 2006, at 3:10 PM, WHIRLYCOTT wrote:
Milliseconds. I'd be fairly skeptical about anybody doing reliable
millisecond timings on a jvm!
^
Sorry, correcting myself. That should have been 'micro'.
Timings are i
Milliseconds. I'd be fairly skeptical about anybody doing reliable
millisecond timings on a jvm!
phil.
On Oct 11, 2006, at 3:05 PM, Kevin Lewandowski wrote:
I've searched the docs but could not find an answer. Is this field
microseconds or milliseconds?
thanks,
Kevin
--
16 matches
Mail list logo
