-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Performance test API keys in Elasticsearch #49397
Comments
Pinging @elastic/kibana-stack-services (Team:Stack Services) |
For volume testing, I created 320,000 API keys and did not notice any slow downs when using an API key. It is worth noting there isn't pagination on the GET API key API. This isn't an endpoint we use but we will definitely create a lot of API keys for each user of alerting. Closing for now as there isn't a performance impact in alerting. |
Did you happen to notice a size increase in the ES disk usage? I'm guessing there might be a hit there. |
I didn't think of taking a look at that but there could be. Are you talking about disk size usage or I/O usage? |
Disk usage. I would expect i/o usage to not be a big factor. But if you created 300K things and didn't see memory bloat, they must have gotten saved to disk, instead of memory :-) |
Now that we show API keys in the UI ( with #45740 ) would all these alerting API keys cause an issue? I think ideally the keys will be created by the kibana system user (on behalf of the logged in user) so it should not pollute or affect this view at all. |
I think the deal is that we re-create them often, I can't remember why off the top of my head. And IIRC, we may not be cleaning them up, because it was unclear when we knew they could be cleaned up (ie, deleted). I might be wrong, those might have been some early issues that we've resolved. Having the management UI for those is great, as we should easily be able to see if we're creating a bunch. I'll bring it up next time I do some stress testing, see what it looks like ... |
Since we'll be using a large number of API keys in Elasticsearch. It would be great to know what performance limitations we may hit with it.
What would happen if a lot of keys are created and then invalidated. (I see some Elasticsearch APIs providing previously invalidated API keys and curious if the array will keep growing).
The text was updated successfully, but these errors were encountered: