-
Notifications
You must be signed in to change notification settings - Fork 8.1k
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
[TSVB] Improve schema validation performance #97061
Comments
Pinging @elastic/kibana-app (Team:KibanaApp) |
Point 1 is directly related to #78351 |
@wylieconlon interesting point. I thought we validate schema only on development mode. Initially we used that validation for telemetry and then it allowed us to find some errors in schema working with JS files. Now the following code doesn't have a lot of sense especially for production.
You plan probably is good but I suggest:
@stratoula any ideas? |
We introduced this a while back to check whether our schema is containing all of the real world cases - we actually found a bunch of edge cases this way, but if it's hurting performance this badly, IMHO we should remove it until we find a better solution. |
Yes I agree let's remove it. Move to TS is really important, not sure if we can make it for 7.14 but let's see how it goes |
* [TSVB][performance] remove visPayloadSchema.validate Part of: #97061 * Update vis.ts
* [TSVB][performance] remove visPayloadSchema.validate Part of: elastic#97061 * Update vis.ts
Thanks @alexwizp I've run some comparisons before and after your commit, also including the other optimizations that I'm testing locally (improved KQL handling of * query and caching uiSettings). What I'm seeing is that removing TSVB schema validation is a 20-25% improvement over the state I showed in the issue: cc @pgayvallet yes, it looks like even if we remove overhead on all the TSVB requests we are still seeing the schema checking being a bottleneck. |
* [TSVB][performance] remove visPayloadSchema.validate Part of: elastic#97061 * Update vis.ts
This is the last and most important piece of improving TSVB performance in a dashboard. I have been profiling a dashboard that uses 46 panels of TSVB using the
metricbeat-*
andfilebeat-*
index patterns, but this dashboard I'm testing is totally empty- I have no matching data, so all the visualizations are empty. I've been able to optimize other parts of the request to return in 2-3 seconds, down from 8-10 seconds before, but the schema validation performance is our biggest bottleneck.As you can see in this screenshot, the schema validation code is the slowest part of loading the dashboard:
I don't have a solution to this issue yet, but brainstorming some possibilities:
cc @alexwizp
The text was updated successfully, but these errors were encountered: