# Negative Search Latency in Marvel

**URL:** https://discuss.elastic.co/t/negative-search-latency-in-marvel/54012
**Category:** Elasticsearch
**Tags:** elastic-stack-monitoring
**Created:** [June 27, 2016, 8:44am UTC](https://discuss.elastic.co/t/negative-search-latency-in-marvel/54012 "2016-06-27T08:44:40Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![haizaar](https://avatars.discourse-cdn.com/v4/letter/h/3d9bf3/32.png) [@haizaar](https://discuss.elastic.co/u/haizaar)
#### Post date: [June 27, 2016, 8:44am UTC](https://discuss.elastic.co/t/negative-search-latency-in-marvel/54012/1 "2016-06-27T08:44:40Z")

</div>

I'm using the free edition of Marvel with ES 2.3.3. Today I've spotted **negative** search latency in graph:

 ![](https://us1.discourse-cdn.com/elastic/original/2X/b/bbf654bca99c6030ea4fbfe4658c17f637515cc5.png)

Any comments?

---

<div class="post-metadata">

### Author: ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)
#### Post date: [June 29, 2016, 12:48am UTC](https://discuss.elastic.co/t/negative-search-latency-in-marvel/54012/2 "2016-06-29T00:48:23Z")

</div>

Woah, you must have awesome hardware!

(Actually I have nothing helpful to add, sorry :p)

---

<div class="post-metadata">

### Author: ![pickypg](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/pickypg/32/62409_2.png) [@pickypg](https://discuss.elastic.co/u/pickypg)
#### Post date: [June 29, 2016, 2:08pm UTC](https://discuss.elastic.co/t/negative-search-latency-in-marvel/54012/3 "2016-06-29T14:08:40Z")

</div>

Hi Zaar Hai,

I'd like to tell you that we're predictively pre-searching for you, but this is a visualization bug that comes from how we calculate the the latency:

Search Latency is calculated by dividing the _derivative_ of the total search time by the _derivative_ of the total search count. Index Latency is the same thing. The derivative is necessary because the stats reported from Elasticsearch itself are just counters since the node started, so each time bucket (x coordinate) gets this extra step applied to avoid a useless display for this type of data.

In the above screenshot, my _guess_ is that you were restarting the node a bunch of times, thus allowing those counters to be reset, which means one of the derivatives was lower (negative) combined with the rest of the data. Please let me know if that's not the case because it would be good to chase down how you ended up getting so many negatives.

Thanks

---

<div class="post-metadata">

### Author: ![haizaar](https://avatars.discourse-cdn.com/v4/letter/h/3d9bf3/32.png) [@haizaar](https://discuss.elastic.co/u/haizaar)
#### Post date: [June 29, 2016, 3:44pm UTC](https://discuss.elastic.co/t/negative-search-latency-in-marvel/54012/4 "2016-06-29T15:44:28Z")

</div>

Nice!

I was not restarting nodes - I've joined node into the cluster after it was  
down for two days and after ES relocated shards on it, I've played with  
shard relocation speed by altering `exclude._ip` params.  
During this later interval I've saw the negative latency.

Thanks,  
Zaar

---

<div class="post-metadata">

### Author: ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)
#### Post date: [July 6, 2017, 1:42pm UTC](https://discuss.elastic.co/t/negative-search-latency-in-marvel/54012/5 "2017-07-06T13:42:52Z")

</div>


