# Kibana 5.5 visualization display slower than Kibana 4.6

**URL:** <https://discuss.elastic.co/t/kibana-5-5-visualization-display-slower-than-kibana-4-6/104475>\
**Category:** Kibana\
**Created:** [October 19, 2017, 2:30am UTC](https://discuss.elastic.co/t/kibana-5-5-visualization-display-slower-than-kibana-4-6/104475 "2017-10-19T02:30:32Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![dsun](https://avatars.discourse-cdn.com/v4/letter/d/13edae/32.png) [@dsun](https://discuss.elastic.co/u/dsun)\
**Post date:** [October 19, 2017, 2:30am UTC](https://discuss.elastic.co/t/kibana-5-5-visualization-display-slower-than-kibana-4-6/104475/1 "2017-10-19T02:30:32Z")

</div>

Hello,

We recently updated our stack to ES 5.5 with Kibana 5.5.3, and we noticed that some of our previous use cases on Kibana tend to be much slower than with our previous Kibana 4.6 experience. The problem seems to be related to the Kibana web app, and not ES as the query runs as fast as before.

The typical use case is basically the following:  
(1) make a vertical bar chart visualization  
(2) click on the arrow below the visualization to display the table containing the data  
(3) change the page size to "All"

The step (3) above takes:

- Kibana 4.6: ~5s
- Kibana 5.5.3: \> 1min (sometimes longer)

Sometimes, even just the step (2) can take around 30s.

I used Chrome's task manager to check the memory used by the tab, and it seems that Kibana 5.5.3 is consuming much more memory than Kibana 4.6, which may be the cause of the problem?

Memory used by the tab, as measured by Chrome's task manager:

- Kibana 4.6: ~300MB-500MB
- Kibana 5.5.3: ~900MB-1.3GB (saw 1.5GB, and climbs very quickly towards 1GB)

Granted, we tend to show lots of data but we did not expect that this use-case would be slower on Kibana 5.5. We like to use a visualization prior to see all the data in a table, as it is handy to see the overall data "shape" first.

Is there any plan on improving this in future versions of Kibana 5.5? Or do you know any workaround that could be useful for this use-case?

Any help on this would be welcome as this is quite frustrating sometimes..

Thanks!  
David

---

<div class="post-metadata">

**Author:** ![apyshchyk](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/apyshchyk/32/23303_2.png) [@apyshchyk](https://discuss.elastic.co/u/apyshchyk)\
**Post date:** [October 23, 2017, 7:06pm UTC](https://discuss.elastic.co/t/kibana-5-5-visualization-display-slower-than-kibana-4-6/104475/2 "2017-10-23T19:06:23Z")

</div>

Have the same issue with new Kibana.  
Described it here - [Dashboard performance issue · Issue #14514 · elastic/kibana · GitHub](https://github.com/elastic/kibana/issues/14514)

Basically - reason because of adding  
{  
"query\_string": {  
"query": "\*",  
"analyze\_wildcard": true  
}  
},

automatically to visualization  
and added comment with screenshots here in forum

> [@Dashboard performance issue](https://discuss.elastic.co/t/dashboard-performance-issue/104954):
>
> Kibana 5.5: Elasticsearch 5.5: CentOS 7: all browsers: Hi all, I noticed huge performance issue with Kibana Dashboards. I have Visualization, already tuned to use "match\_all": {} for better performance [[image] ](https://user-images.githubusercontent.com/10866345/31900991-da40fbf6-b828-11e7-8821-981653a71dbb.png) but when I add this visualization to dashboard, and look into generated request, I have different request, which works slower [[image] ](https://user-images.githubusercontent.com/10866345/31900875-872def0a-b828-11e7-9de5-a797d23daffc.png) Why Dashboard modified visualization query in such way? How to prevent Dashboar…

---

<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:** [November 20, 2017, 7:06pm UTC](https://discuss.elastic.co/t/kibana-5-5-visualization-display-slower-than-kibana-4-6/104475/3 "2017-11-20T19:06:39Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
