grafana-image-renderer
grafana-image-renderer copied to clipboard
POC: Massive performance boost experiment with no full page reloads between renders
Fixes #124
This is a very hacky POC to explore the biggest potential avenue for performance improvement, getting rid of full-page reloads between image renderings.
The first image takes the normal amount of time: 2-3 seconds
After that, the image renderings take about 200 - 300ms (assuming the panel queries are very fast)
This needs a lot more work to be production-ready. There could be big security issues with this approach that needs to be investigated. And more complex logic that validates that the rendered panel is for the same instance and org as the last render request, need a way to cache browser pages per org.
Todo
- [ ] Address security concerns
- [ ] Cache pages per org & user
- [ ] Every 50x render (or some number) do a full page reload to avoid memory leaks causing issues
- [ ] Fix rendering different panel on same dashboard (should be easy)
- [ ] Need not reuse for concurrent requests
- [ ] Needs updates to SoloPanelPage to support navigating between dashboards (needs cleanup), and panel on the same dashboard.
nice workaround :+1:
The blocker with this approach is authentication managed with renderKey
-- since it is a cookie (and must be a cookie) we can't share a page/context across multiple requests with different users.
In #314 @ArturWierzbicki has extended the concurrency mode so that requests with the same render key will keep the same session/cache etc. But this will not yet help the general case.
The blocker with this approach is authentication managed with
renderKey
-- since it is a cookie (and must be a cookie) we can't share a page/context across multiple requests with different users.In #314 @ArturWierzbicki has extended the concurrency mode so that requests with the same render key will keep the same session/cache etc. But this will not yet help the general case.
Created a working PoC in grafana-core for the general case, ie. when a single user issues multiple render requests in a short time window.
The implementation is pretty simple - it leverages the new contextPerRenderKey mode and persists the combination of renderKey
/userId
/orgId
/orgRole
in the DB. Keys are valid for 10 minutes unless refreshed via a new render request from the same user.