Move hashing on API key creation to crypto thread pool #74165
Conversation
ywangd
added
>enhancement
:Security/Security
|
Pinging @elastic/es-security (Team:Security) |
|
This does mean that API key creation is potentially slower (due to intentionally limiting the number of concurrent threads that will do crypto), so I think it's worth making @ruflin and @scunningham aware. Overall it should be better from a QoS point of view because it reduces the likelihood that API Key creation will steal CPU time from ingestion. But the effect could show up as a change in some benchmarks that focus on API Key setup. |
|
Does the team have benchmarks in place that will show the diff if there is one? |
No I am not aware of any benchmarks that are focused on creating API keys. The crypto thread pool by default has half of the allocated processors while the |
The changes in elastic#74106 make API keys cached on creation time. It helps avoid the expensive hashing operation on initial authentication when a request using the key hits the same node that creates the key. Since the more expensive hashing on authentication time is handled by a dedicated "crypto" thread pool (elastic#58090), it is expected that usage of the "crypto" thread pool to be reduced. This PR moves the hashing on creation time to the "crypto" thread pool so that a similar (before elastic#74106) usage level of "crypto" thread pool is maintained. It also has the benefit to avoid costly operations in the transport_worker thread, which is generally preferred. Relates: elastic#74106
The changes in #74106 make API keys cached on creation time. It helps avoid the expensive hashing operation on initial authentication when a request using the key hits the same node that creates the key. Since the more expensive hashing on authentication time is handled by a dedicated "crypto" thread pool (#58090), it is expected that usage of the "crypto" thread pool to be reduced. This PR moves the hashing on creation time to the "crypto" thread pool so that a similar (before #74106) usage level of "crypto" thread pool is maintained. It also has the benefit to avoid costly operations in the transport_worker thread, which is generally preferred. Relates: #74106
Since elastic#74165, API key creation has one additional async layer. Hence the test assertions are now executed asynchronously and may not get called in time before the test ends. This PR ensures the assertions are always called by waiting for a flag. Resolves: elastic#74427
…#74431) Since elastic#74165, API key creation has one additional async layer. Hence the test assertions are now executed asynchronously and may not get called in time before the test ends. This PR ensures the assertions are always called by waiting for a flag.
The changes in #74106 make API keys cached on creation time. It helps avoid the expensive hashing operation on initial authentication when a request using the key hits the same node that creates the key. Since the more expensive hashing on authentication time is handled by a dedicated "crypto" thread pool (#58090), it is expected that usage of the "crypto" thread pool to be reduced.
This PR moves the hashing on creation time to the "crypto" thread pool so that a similar (before #74106) usage level of "crypto" thread pool is maintained. It also has the benefit to avoid costly operations in the
transport_workerthread, which is generally preferred.Relates: #74106