To reduce cache misses we should round up the lower bound of the time picker. This is something we could do for APM only, Observability-wide or platform wide. It's probably easiest/quickest to do it just for
APM and then look to expand it.

Example

                        "from": 1605279417058, 3days
                        "to": 1605538617059,

The millisecond precision here will cause all of the dashboards to miss the cache. If, say, they rounded 1605279417058 to 1605279400000 and 1605538617059 to 1605538620000 they are more likely to hit the cache. I've recommended to them in the past that they at least round down the lower range because folks are less sensitive to having a few extra hours or minutes on the low end and the shards on the low end tend to be on slower hardware. They could round up on the upper end but its not as likely to matter because the cache is constantly cleared when there are writes to the shard and the upper end will be getting writes all the time. But rounding up might help long running request for the same dashboard "merge" at the shard request caching layer.