search

elastic / kibana

Your window into the Elastic Stack
https://www.elastic.co/products/kibana
Other
19.66k stars 8.1k forks source link

Charts render slow with big number of buckets #8159

Closed ppisljar closed 5 years ago

ppisljar commented 7 years ago

Kibana 4/5 renders charts much slower than kibana 3. Since kibana 3 used canvas to render the charts and now we are using svg based charts it is by default slower, still improvements can be made to the current implementation to make it faster.

JacobBrandt commented 7 years ago

@ppisljar Do you know of any plans to move back to canvas based charts or an option to change your rendering preference? Maybe even a bucket threshold that switches to canvas based rendering when the bucket size is over some user setting.

I know for the most part the svg based charts work until like you say large buckets are needing to be rendered and then Kibana just crashes basically. I'm hoping this enhancement is not going to be abandoned.

ppisljar commented 7 years ago

there are no short term plans at this time. timelion and time series visual builder are already using canvas based rendering technology

JacobBrandt commented 7 years ago

@ppisljar Thanks for the info. I ended up switching the ColumnChart to be canvas based for my needs because even timelion could not accomplish what was needed. With timelion you have to click the labels to do any filtering, which only just hides that value and does not apply it as a filter pill. Even if it did, at only 50 discrete labels that makes it unusable as the labels run off of the visualization space. Also, not all of my users are savvy enough to use timelion even though it's pretty straight forward.

Switching the ColumnChart to canvas based was obviously a huge performance increase. It also fixes an issue where the bar chart doesn't limit the number of buckets rendered. This was a big deal because without it being canvas based javascript crawls and eventually gives you the long running script error. It sometimes even crashes when you say to continue. If it does finish rendering than Kibana is really slow because of layout thrashing (thousands upon thousands of svg rects). Ideally this data should be displayed in a heat map not a stacked bar chart but ironically that visualization wouldn't allow the same number of series as a bar chart does.

I think at the very least it would be nice short term to limit the bar chart like other visualizations so at least Kibana doesn't get into this slow unusable state or worse crash. Then long term reconsider canvas based visualizations.

nreese commented 6 years ago

@JacobBrandt There is a PR out that will limit the histogram aggregation from creating more bars than the number specified in Advanced Setting's histogram:maxBar. This should help minimize some of the performance problems.

JacobBrandt commented 6 years ago

@nreese That doesn't solve performance problems. It just limits the number of bars to draw. We solved the performance problems by rendering the chart on a canvas as mentioned earlier.

timroes commented 5 years ago

We discussed this issue and decided to close it for two reasons: a) It's too generic, since you will always be able to improve performance and thus we would never be able to close this issue b) we're looking into reimplementing the charts (https://github.com/elastic/kibana/issues/17234) in EUI with a cleaner approach and that approach will allow us to reevaluate canvas usage over SVG.