+++ This bug was initially created as a clone of Bug #767205 +++ Description of problem: When the server requests content for files previously reported, the agent receives a list of SHAs. The agent then performs a reverse look up, finding the corresponding file system path for each SHA. This involves reading the current snapshot file. The problem is that the snapshot file is read over and over again for each SHA. When the server sends a lot of SHAs, like with the initial snapshot, this results in excessive and unnecessary IO. The agent only needs to read the snapshot file once. Doing so will increase the memory usage for the duration of that method call; however, the overall execution time for the method will substantially be reduced as the number of SHAs passed to it increases in size. The increased memory footprint is likely on the order of bytes or 10s of kilobytes whereas the decrease in execution time could be on the order of milliseconds or seconds. For testing, this should result in no change in functionality other than increased logging. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: --- Additional comment from jsanda on 2011-12-14 21:01:47 EST --- DriftFilesSender has been refactored so that it only reads the snapshot file on disk once when looking up files by SHA. master commit hash: 9f18aee38ed44f992ce26e7f8141a057af716533 --- Additional comment from mfoley on 2011-12-15 14:11:48 EST --- verified thru ad hoc testing on drift feature
Fix has been pushed to release/jon3.0.x branch. commit hash: 4886f73e5afb984f4039318da21cc5fbd37482bc
Setting to MODIFIED while waiting for this to appear in a build
Moving this to ON_QA as new RC3 binary available here: https://brewweb.devel.redhat.com//buildinfo?buildID=198086
smoke tested Drift
Bulk closing of old issues in VERIFIED state.