A note on performance in the registry control plane
Reducing repeated registry work with cached catalog data, paginated tag loading, and event-driven cache warming.
- Removing repeated work from the registry paths used most often.
- Caching repository catalog data instead of rebuilding it on each load.
- Using paginated tag pages and cached tag summaries for repeated lookups.
- Warming useful cache paths from registry events and separating background work from interface loading.
On this page
The repeated paths
I focused this work on the registry paths the app uses most often, where the same catalog and tag data was being assembled again for repeated views. This was not a broad benchmark of the service. It was a follow-up on routine operator paths that were doing work the control plane had already done.
Reducing duplicate work
I cached repository catalog data, moved tag pages to paginated loading, and added cached tag summaries for repeated lookups. Those changes keep a repeated view from paying again for work the service has already done.
Registry events now warm useful cache paths. I also separated background work from interface loading so that maintenance activity does not hold up the operator view.
Scope of the follow-up
The result is less repeated work on ordinary operator paths and a clearer boundary between registry activity and the interface used to manage it. It is part of the same operating work described in the original Registry Control Plane snapshot, alongside the responsive interface follow-up.
For the current project overview, see Registry Control Plane. The related Forgejo runner cache work addressed a different repeat-cost problem in the build path rather than in the operator interface.