Saved‑objects cache enabled or disabled for Kibana dashboard latency under concurrent load?

Goal: Determine whether to enable Kibana’s saved‑objects cache to reduce latency under concurrent dashboard loads while accepting possible metadata staleness, or to disable the cache to guarantee up‑to‑date saved objects at the cost of higher response times.

Constraints: With the cache enabled (xpack.security.savedObjects.enabled: true) lookup latency drops, keeping 95th‑percentile response below ~500 ms for up to 200 concurrent users, but changes to saved objects are not visible until the cache expires (default 5 minutes). Disabling the cache forces each request to read the .kibana index, which can push the same metric above 1.2 s under the same load, especially when the index is large or the cluster is busy. The cache TTL requires a Kibana restart and applies uniformly across all spaces, so fine‑grained per‑space tuning is not available, and the exact numbers vary with Kibana version, ES cluster size, and network conditions.

Should the saved‑objects cache be enabled to keep 95th‑percentile latency under 500 ms for up to 200 concurrent users, accepting a maximum staleness of 5 minutes? Is there a way to mitigate staleness without sacrificing the latency benefit, such as per‑space TTL or automatic cache invalidation when a saved object is modified?