-
Notifications
You must be signed in to change notification settings - Fork 8.5k
Optimize performance of ES privilege response validation #90074
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
Conversation
|
@elasticmachine merge upstream |
|
Pinging @elastic/kibana-security (Team:Security) |
jportner
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good, I have one question below. Did not benchmark with Kibana running like you did, since I don't have that script handy.
…na into chore/check-privileges-perf
jportner
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
I was going to package it up as part of this PR in case you wanted to test it yourself, but it's a messy little Node.js app that isn't suitable for anyone other than myself right now 🙂 |
|
jenkins test this |
💚 Build SucceededMetrics [docs]
History
To update your PR or re-run it, just comment with: |
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Summary
Optimizes the performance of our response validation when we make a call to Elasticsearch's
_has_privilegesendpoint. Resolves #90016This validation is currently performed by building a custom Joi schema. This works well most of the time, but does not scale when there is a large number of
resources, due to the way we were building the validation schema.My profiling indicates that it takes a lot of time to build the schema, but not a lot of time to actually perform the validation using the schema. As such, this PR changes the way the schema is built, but otherwise maintains parity with the existing implementation.
This PR moves the validation from
Joito@kbn/config-schemafor a couple of reasons:@kbn/config-schemais the preferred validation frameworkJoiunder the covers, so the updated validation is very close the original implementation (low risk)Joi, but it is not as friendly to do.How I tested
yarn es snapshot)Prior to this change, one such run showed that the entire request took almost
5 seconds, with4.3seconds spent in the response validationAfter this change, one such run showed that the entire request took under
1 second, with less than500msspend in the response validation