`juju status keystone` is 5x slower than `juju status`

[James Troup]

$ /usr/bin/time --verbose juju status keystone 2>&1 | grep Elapsed
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:25.04
$ /usr/bin/time --verbose juju status 2>&1 | grep Elapsed
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:04.46
$ juju controllers --refresh
Controller Model User Access Cloud/Region Models Nodes HA Version
foundations-maas* test-lma2-microk8s admin superuser maas_cloud/default 6 146 3 2.9.16
test-microk8s test-lma2 admin superuser test-microk8s/localhost 2 - - 2.9.18
$

[Joseph Phillips (manadart)]

This will be due to leaning heavily on the internal model cache for full status.

[Heather Lanigan (hmlanigan)]

Part of the issue as well, is how we use fuzzy logic for filters and have to search all of the status, rather than knowing what type of thing we're looking to filter.

[Canonical Juju QA Bot (juju-qa-bot)]

This Medium-priority bug has not been updated in 60 days, so we're marking it Low importance. If you believe this is incorrect, please update the importance.

[Andrea Ieri (aieri)]

I think this should be kept as medium; the performance gap is still there.

$ /usr/bin/time --verbose juju status keystone 2>&1 | grep Elapsed
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:08.15
$ /usr/bin/time --verbose juju status 2>&1 | grep Elapsed
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:01.73

^ tested on a 2.9.31 controller