Hide Forgot
The current naive implementation of the web app calls out to the remote Pulp servers directly in the page rendering process. This is basically only usable when the PulpDist web app and the configured Pulp server(s) are all on the same LAN - pages become very slow to render if there is a high latency WAN connection between the two servers. This is basically the exact problem that memcached is intended to address - we don't really need a full blown backend daemon (that's what Pulp is for!), just somewhere to stash the data that doesn't change very often (such as the list of repositories on the server) so we don't have to look it up on the remote server all the time. Longer term, we can add a small daemon that uses AMQP message traffic to update and/or invalidate cache entries based on changes made to the Pulp repos.
(The in-memory cache doesn't *specifically* have to be memcached - part of addressing this issue would be looking at the available options like memcached and Redis, and choosing one).
Marking all remaining PulpDist issues as CLOSED-EOL It doesn't make sense to leave these issues open, as PulpDist hasn't been in active development for quite some time, and restarting development would involve a significant modernisation effort that would likely render many of these requests irrelevant.