# @timestamp term tables make dashboard very slow

**URL:** <https://discuss.elastic.co/t/timestamp-term-tables-make-dashboard-very-slow/149376>\
**Category:** Kibana\
**Created:** [September 21, 2018, 2:11am UTC](https://discuss.elastic.co/t/timestamp-term-tables-make-dashboard-very-slow/149376 "2018-09-21T02:11:20Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![tsullivan](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/tsullivan/32/31077_2.png) [@tsullivan](https://discuss.elastic.co/u/tsullivan)\
**Post date:** [September 21, 2018, 8:26pm UTC](https://discuss.elastic.co/t/timestamp-term-tables-make-dashboard-very-slow/149376/2 "2018-09-21T20:26:23Z")

</div>

> [@Sjaak01](#):
>
> Despite the request duration being less than 3 seconds, it takes over 30 for a browser to render this single visualization. For some reason performance doesn't scale very well between 30 and 60 days either while performance between 60 and 90 days does seem to scale better.

You'll have to think about the number of [aggregation buckets](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket.html) coming over the network and getting parsed in the browser. The Elasticsearch APIs return JSON data, which is parsed as a single string into Javascript objects in the browser. The Javascript runtime environment is a single thread (this is true as of the time writing this, because Kibana doesn't implement web workers), and parsing JSON is a CPU-intensive blocking operation.

So the more buckets in the Elasticsearch result, the larger the data string, and the longer it takes to parse. If you're using timestamp as the term to aggregate on, and you a document for every, say hour, a 90-day search would come up with about 129600 buckets. If you have sub-aggregations (split rows) the amount of data coming back is some multiple of that.

Along with that, Kibana proxies the entire response from Elasticsearch straight into the browser, to help with inspection. It doesn't filter or map the response to reduce the payload size.

It could be that you are trying to represent something like the actual raw documents in a table visualization. Have you thought of instead [adding Saved Searches to your dashboard](https://discuss.elastic.co/t/display-search-results-in-dashboard/66337)?

If Kibana has no built-in solutions that are appropriate for what you're trying to do, you could also think about building a custom visualization plugin that executes custom searches that using ES tools like [source filtering](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-source-filtering.html), [field collapsing](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-collapse.html), and [composite aggregation](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-composite-aggregation.html) to reduce the result data down to a more manageable size. If you can get your data with a query as opposed to an aggregation, or get it from a composite aggregation, the JSON data string will be much smaller as the values in the data will have way less depth.

---

_[View the full topic](https://discuss.elastic.co/t/timestamp-term-tables-make-dashboard-very-slow/149376)._
