Open pmuellr opened 3 years ago
Pinging @elastic/kibana-alerting-services (Team:Alerting Services)
Depending on the outcome of this issue, we should revisit if it's worth keeping all the connectors in memory in the UI and what it means for the get all API in a non-breaking manner.
Should point out that this is only a problem for a space that has > 10K connectors, which seems like it's a problem we can defer for quite a while.
There are some related issues noted here: https://github.com/elastic/kibana/issues/116776
We may be blocked on new API / function from saved objects to resolve this.
Can we limit the number of connectors per space to 10k for now? 🤷 Kind of feels like an unrealistic scenario to have more than 10k connectors... and if we discover it isn't we can address it properly.
Happened to be doing some stress testing of Kibana, figured out a handy way to create 100K connectors in under 4 minutes, using
autocannon
.autocannon-connectors.sh
```sh #/usr/bin/env bash autocannon \ --connections 1000 \ --amount 100000 \ --workers 50 \ --method POST \ --body '{"actionTypeId":".server-log","name":"server-log","config":{},"secrets":{}}' \ --timeout 60 \ --headers kbn-xsrf=what-evs \ --headers content-type=application/json \ --latency \ --renderStatusCodes \ --debug \ $KBN_URL/api/actions/action ```When I visit the connectors list page after that's done, I see this:
Note, 10 per page, 1001 pages is ~10K connectors. I'm expecting more around ~100K.
Here's what Discover shows me, which is a little larger than I expected actually - 99,998 - I was expecting 99,981 as that was the number
autocannon
reported as succeeding (not timing out). I guess a request timed out, but still ran on the server, creating the connector, so this is the actual number that "succeeded" as far as the server goes.I think this 10K number is burned into a number of places in alerting and/or saved objects. But still seems like we should be able to get the real number and display it in the footer. And of course navigate to any page!