Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slow doc table rendering with large number of fields #6328

Closed
marcinkubica opened this issue Feb 25, 2016 · 2 comments
Closed

Slow doc table rendering with large number of fields #6328

marcinkubica opened this issue Feb 25, 2016 · 2 comments
Labels
bug Fixes for quality problems that affect the customer experience v5.1.1

Comments

@marcinkubica
Copy link

Hi

Kibana 4.4.1

I've got this problem on Chrome. Also seen on IE which I don't use. As you can see from recording below.

I'm running dashboard with 20 vis against 40m records and it is unable to finish loading.
However, all seem to work much better on Firefox, where it can finish in about 48 seconds.
On Chrome just opening Discovery for marvel last 15 minutes takes 90s.

Screen recording is from Windows. I've also linked saved timeline (that one done on Linux)

We've been discussing this with @spalger so he can provide you with more info regarding the fix he has. Also adding screenshots from his version I've been testing, both Firefox and Chrome are fine. It bombs out on IE though :D Would be smashing to have the fix in 4.5 though.

Cheers

2016-02-25_04-20-04

1_timeline_capture

2_timeline_capture

TImeline for Discovery from example above:
https://drive.google.com/file/d/0B0MB1KHD29RbaUw0X3hhQTg3UXM/view?usp=sharing

Spalger's version against 8k marvel Discovery

image

Spalger's version for my 20vis against 40m records

image

@rashidkpc
Copy link
Contributor

@spalger can you fill in details here?

@spalger
Copy link
Contributor

spalger commented Mar 1, 2016

This is a behavior that I have been seeing in Chrome Canary on a pretty regular basis, but I figured it was just a weird behavior that Canary has, but Main Stream Chrome doesn't seem to have.

The fix that @marcinkubica mentioned is a re-write of the doc table as a React component. Using React in this way seems to seriously trim down the render time, but the implementation is not complete as it simply renders all of the sample rows (no infinite scroll) and none of it is tested. See #6370 for details.

@rashidkpc rashidkpc changed the title Huge performance hit on Chrome Slow doc table rendering with large number of fields Mar 3, 2016
@rashidkpc rashidkpc added bug Fixes for quality problems that affect the customer experience P1 and removed feedback_needed labels Mar 3, 2016
Bargs added a commit to Bargs/kibana that referenced this issue Nov 9, 2016
Back in 2014 a utility was added to insert <wbr> (word break opportunity)
tags into doc table fields to improve their display in the browser. This
utility looped over every character in _source when it was selected as a
column in the doc table, which it was be default. That really started to
slow things down when displaying large docs. I compared how the browser
renders things with and without the <wbr>'s and there's almost no
difference, certainly nothing as dramatic as shown in the linked PR
which added this word breaking functionality. Perhaps browsers have
improved in the last two years, or perhaps something changed in our CSS.
Since we're getting no or negligible value from this utility and it
makes Discover impossible to use with large docs, I simply removed it.

Fixes elastic#6328
Related elastic#1993
Bargs pushed a commit that referenced this issue Nov 14, 2016
Back in 2014 a utility was added to insert <wbr> (word break opportunity)
tags into doc table fields to improve their display in the browser. This
utility looped over every character in _source when it was selected as a
column in the doc table, which it was be default. That really started to
slow things down when displaying large docs. We can maintain similar word 
breaking without adding <wbr> tags by adding some css styles that 
do essentially the same job. word-break: break-word gives us the best 
formatting but it's not a part of the standard yet (see link below) so I 
provided an almost-as-good fallback with break-all.

https://bugs.chromium.org/p/chromium/issues/detail?id=492202#c21

Fixes #6328
Related #1993
Bargs pushed a commit that referenced this issue Nov 15, 2016
Backports PR #9014

**Commit 1:**
Speed up rendering of large docs in doc table

Back in 2014 a utility was added to insert <wbr> (word break opportunity)
tags into doc table fields to improve their display in the browser. This
utility looped over every character in _source when it was selected as a
column in the doc table, which it was be default. That really started to
slow things down when displaying large docs. I compared how the browser
renders things with and without the <wbr>'s and there's almost no
difference, certainly nothing as dramatic as shown in the linked PR
which added this word breaking functionality. Perhaps browsers have
improved in the last two years, or perhaps something changed in our CSS.
Since we're getting no or negligible value from this utility and it
makes Discover impossible to use with large docs, I simply removed it.

Fixes #6328
Related #1993

* Original sha: fc443bb
* Authored by Matthew Bargar <[email protected]> on 2016-11-09T00:11:45Z

**Commit 2:**
Improve word breaking in doc table

To maintain similar word breaking without adding <wbr> tags I've added
some css styles that do essentially the same job. word-break: break-word
gives us the best formatting but it's not a part of the standard yet
(see link below) so I provided an almost-as-good fallback with
break-all.

https://bugs.chromium.org/p/chromium/issues/detail?id=492202#c21

* Original sha: ac38524
* Authored by Matthew Bargar <[email protected]> on 2016-11-10T23:01:30Z
Bargs pushed a commit that referenced this issue Nov 15, 2016
Backports PR #9014

**Commit 1:**
Speed up rendering of large docs in doc table

Back in 2014 a utility was added to insert <wbr> (word break opportunity)
tags into doc table fields to improve their display in the browser. This
utility looped over every character in _source when it was selected as a
column in the doc table, which it was be default. That really started to
slow things down when displaying large docs. I compared how the browser
renders things with and without the <wbr>'s and there's almost no
difference, certainly nothing as dramatic as shown in the linked PR
which added this word breaking functionality. Perhaps browsers have
improved in the last two years, or perhaps something changed in our CSS.
Since we're getting no or negligible value from this utility and it
makes Discover impossible to use with large docs, I simply removed it.

Fixes #6328
Related #1993

* Original sha: fc443bb
* Authored by Matthew Bargar <[email protected]> on 2016-11-09T00:11:45Z

**Commit 2:**
Improve word breaking in doc table

To maintain similar word breaking without adding <wbr> tags I've added
some css styles that do essentially the same job. word-break: break-word
gives us the best formatting but it's not a part of the standard yet
(see link below) so I provided an almost-as-good fallback with
break-all.

https://bugs.chromium.org/p/chromium/issues/detail?id=492202#c21

* Original sha: ac38524
* Authored by Matthew Bargar <[email protected]> on 2016-11-10T23:01:30Z
elastic-jasper added a commit that referenced this issue Nov 18, 2016
Backports PR #9014

**Commit 1:**
Speed up rendering of large docs in doc table

Back in 2014 a utility was added to insert <wbr> (word break opportunity)
tags into doc table fields to improve their display in the browser. This
utility looped over every character in _source when it was selected as a
column in the doc table, which it was be default. That really started to
slow things down when displaying large docs. I compared how the browser
renders things with and without the <wbr>'s and there's almost no
difference, certainly nothing as dramatic as shown in the linked PR
which added this word breaking functionality. Perhaps browsers have
improved in the last two years, or perhaps something changed in our CSS.
Since we're getting no or negligible value from this utility and it
makes Discover impossible to use with large docs, I simply removed it.

Fixes #6328
Related #1993

* Original sha: fc443bb
* Authored by Matthew Bargar <[email protected]> on 2016-11-09T00:11:45Z

**Commit 2:**
Improve word breaking in doc table

To maintain similar word breaking without adding <wbr> tags I've added
some css styles that do essentially the same job. word-break: break-word
gives us the best formatting but it's not a part of the standard yet
(see link below) so I provided an almost-as-good fallback with
break-all.

https://bugs.chromium.org/p/chromium/issues/detail?id=492202#c21

* Original sha: ac38524
* Authored by Matthew Bargar <[email protected]> on 2016-11-10T23:01:30Z
Bargs pushed a commit to Bargs/kibana that referenced this issue Nov 18, 2016
Back in 2014 a utility was added to insert <wbr> (word break opportunity)
tags into doc table fields to improve their display in the browser. This
utility looped over every character in _source when it was selected as a
column in the doc table, which it was be default. That really started to
slow things down when displaying large docs. We can maintain similar word
breaking without adding <wbr> tags by adding some css styles that
do essentially the same job. word-break: break-word gives us the best
formatting but it's not a part of the standard yet (see link below) so I
provided an almost-as-good fallback with break-all.

https://bugs.chromium.org/p/chromium/issues/detail?id=492202#c21

Fixes elastic#6328
Related elastic#1993
epixa pushed a commit that referenced this issue Nov 21, 2016
Back in 2014 a utility was added to insert <wbr> (word break opportunity)
tags into doc table fields to improve their display in the browser. This
utility looped over every character in _source when it was selected as a
column in the doc table, which it was be default. That really started to
slow things down when displaying large docs. We can maintain similar word
breaking without adding <wbr> tags by adding some css styles that
do essentially the same job. word-break: break-word gives us the best
formatting but it's not a part of the standard yet (see link below) so I
provided an almost-as-good fallback with break-all.

https://bugs.chromium.org/p/chromium/issues/detail?id=492202#c21

Fixes #6328
Related #1993
@tbragin tbragin added the v5.1.1 label Dec 8, 2016
airow pushed a commit to airow/kibana that referenced this issue Feb 16, 2017
Backports PR elastic#9014

**Commit 1:**
Speed up rendering of large docs in doc table

Back in 2014 a utility was added to insert <wbr> (word break opportunity)
tags into doc table fields to improve their display in the browser. This
utility looped over every character in _source when it was selected as a
column in the doc table, which it was be default. That really started to
slow things down when displaying large docs. I compared how the browser
renders things with and without the <wbr>'s and there's almost no
difference, certainly nothing as dramatic as shown in the linked PR
which added this word breaking functionality. Perhaps browsers have
improved in the last two years, or perhaps something changed in our CSS.
Since we're getting no or negligible value from this utility and it
makes Discover impossible to use with large docs, I simply removed it.

Fixes elastic#6328
Related elastic#1993

* Original sha: fc443bb
* Authored by Matthew Bargar <[email protected]> on 2016-11-09T00:11:45Z

**Commit 2:**
Improve word breaking in doc table

To maintain similar word breaking without adding <wbr> tags I've added
some css styles that do essentially the same job. word-break: break-word
gives us the best formatting but it's not a part of the standard yet
(see link below) so I provided an almost-as-good fallback with
break-all.

https://bugs.chromium.org/p/chromium/issues/detail?id=492202#c21

* Original sha: ac38524
* Authored by Matthew Bargar <[email protected]> on 2016-11-10T23:01:30Z
Former-commit-id: 379abee
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Fixes for quality problems that affect the customer experience v5.1.1
Projects
None yet
Development

No branches or pull requests

5 participants