Project

Profile

Help

Issue #4161

Content Unit Unassociation progress reporting is highly non-granular

Added by dalley almost 2 years ago. Updated about 2 months ago.

Status:
NEW
Priority:
Normal
Assignee:
-
Category:
-
Sprint/Milestone:
-
Start date:
Due date:
Estimated time:
Severity:
2. Medium
Version:
Platform Release:
OS:
Triaged:
Yes
Groomed:
No
Sprint Candidate:
No
Tags:
Sprint:
Quarter:

Description

If you sync a large number of units, then do another mirror sync against a different remote, the task will "apparently" hang for several minutes with no progress being made while it processes content unit unassociations. The progress value is only updated at the end of the process (hence, the end of the task), with no intermittent updates to inform the user of progress.

In my case, with 20,000 units being unassociated, this took nearly half an hour and resulted in believing I was looking at a problem with the tasking system.

Along these lines, content unassociation seemed much slower than association, exacerbating the problem. Perhaps we should investigate unassociation performance.

History

#1 Updated by daviddavis almost 2 years ago

  • Triaged changed from No to Yes

#2 Updated by bmbouter over 1 year ago

  • Tags deleted (Pulp 3)

#3 Updated by dalley about 2 months ago

(pulp) [vagrant@pulp3-source-fedora32 devel]$ python rpm_perf_test.py 
The task was successful.
Sync time: 378 seconds
The task was successful.
Sync time: 504 seconds

Second sync was mirror-mode. It's unclear that the reason it took longer was unassociation vs the actual sync itself (it's probably QueryExistingContent), but it's at least much better than half an hour difference.

I didn't really check progress reporting though, this was a 50,000k unit repo so even if there was no progress report for a minute that's not the worst thing in the world.

Please register to edit this issue

Also available in: Atom PDF