Red Hat Bugzilla – Bug 976848
subman blocks while slowly writing cache of status requests
Last modified: 2013-10-01 09:49:27 EDT
Created attachment 763897 [details]
pycallgraph out of a 'subscription-manager list --consumed" showing time spent writing caches
Description of problem:
To support use offline, subscription-manager will write a cache of
results from server side status checks everytime it get's it.
For systems with a lot of entitlement info, writing out this cache can be noticibly slow. This seems to be caused mostly by json serialization overhead.
See attached pycallgraph-list-consumed.pdf for an example for a system with 16 entitlements. That example is for a cli 'list --consumed' invocation.
In the gui, subman can end up writing out the status cache multiple times. I'll file that as a seperate bug.
1. json serilization is slow
2. the (re-)serialization may be unneccasary, since we get the serialized version from the REST api call, deserialize it, then serialize it again.
3. client (gui, in particular) blocks while doing this. The cache isn't strictly neccasary for operation to continue, so it is not neccasary to wait/block for this to be done. It should be async.
1. faster json serilization (unlikely on rhel5)
2. make cache writing async so gui doesn't block
3. don't write out cache
4. figure out how to use the unserialized result from the connection object to short circuit deserialize from request -> serialized to memory -> deserialized to disk cache loop
Version-Release number of selected component (if applicable):
Anything that supports server side status caching (1.8+ more or less)
Always, but it is easier to see with a lot of entitlements.
Author: ckozak <email@example.com>
Date: Mon Jul 1 11:29:44 2013 -0400
976848: 976851: thread cache write, limit disk reads, singleton
This is an optimization bug/fix, if it is implemented properly, QA tests should not detect any difference.
I do not have any explicit test coverage to confirm that comment 0 was a problem nor assert that comment 0 is now fixed.
I also do not have any metrics to confirm that performance has improved with this bug fix.
As suggested in comment 2, I can say that our automated tests have not revealed a regression in behavior with respect to compliance status that has not already been addressed in other bugzillas. Therefore, I am flipping this bug to VERIFIED without any adverse regression.
[root@jsefler-5 ~]# rpm -q subscription-manager
No comment on that pycallgraph attachment.