-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Search] Load test search sessions vs no search sessions #125384
Comments
cc @crob611 @jb1b84 @sixstringcode |
This would help with starting fewer new searches in some Kibana usage scenarios, so I agree it would help with overall cluster load in some cases. |
I think this is the scenario we should be optimizing for at this point - most real-world usage of solutions means dashboards are created by a subset of users and/or are rarely modified but many users need to view them and do so often. Anything we can do to help a dashboard "hit cache" by default is important |
For general performance, I agree that elasticsearch "cache hit" is definitely something we should optimize for (#94280) But I think it is unrelated to the problem that current search session implementation adds additional load for every search run even until the session is saved by the user. |
Pinging @elastic/kibana-data-discovery (Team:DataDiscovery) |
Currently, search sessions in Kibana are implemented in a way that they add some performance overhead even if the search session is not saved. We are working on improving that aiming to tend search session impact to 0 when they are not saved.
But as of now, these are some load testing results with search sessions on and off:
Conditions
Results
Focusing just on a dashboard scenario
Single Kibana, 2 es nodes (default cloud config)
fill gatling report multiple es nodes.zip
Then I reduced the number of elasticsearch nodes to a single node and the difference in the same testing scenario even more significant:
Single Kibana, singles es node
full gatling report a single es nodes.zip
The text was updated successfully, but these errors were encountered: