Project

Profile

Help

Issue #4161

closed

Content Unit Unassociation progress reporting is highly non-granular

Added by dalley over 5 years ago. Updated over 2 years ago.

Status:
CLOSED - WONTFIX
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.

Actions #1

Updated by daviddavis over 5 years ago

  • Triaged changed from No to Yes
Actions #2

Updated by bmbouter almost 5 years ago

  • Tags deleted (Pulp 3)
Actions #3

Updated by dalley over 3 years 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.

Actions #4

Updated by dalley over 2 years ago

  • Status changed from NEW to CLOSED - WONTFIX

No longer relevant

Also available in: Atom PDF