Bug 1084564
Summary: | dnf initial phase much slower than yum | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> |
Component: | dnf | Assignee: | Packaging Maintenance Team <packaging-team-maint> |
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | akozumpl, mls, packaging-team-maint, pnemade, rholy |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-04-06 11:42:44 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Michal Jaegermann
2014-04-04 16:57:01 UTC
The time to decompress the metadata vs depsolving speed is a tradoff most our users agree to be a good one. We can however get some speedups from background processing as described in bug 1038824. DNF does not throw away valid (nonexpired) metadata. *** This bug has been marked as a duplicate of bug 1038824 *** "Decompression" takes about 1 sec, so that can't make the difference here. This must be some download issue, maybe dnf picked a slow mirror or something like that. Michal, do you get that kind of slowness all the time? Maybe the logs contain some hint to why dnf's download is so slow. (In reply to Michael Schröder from comment #2) > Michal, do you get that kind of slowness all the time? It was prominent enough and prevalent enough to cause me to try to get some data instead of relayin on an impression of a general slugishness. One or two incidents I would dismiss for "just beeing unlucky". I did not need any "heroic efforts" to get quoted times. Just measured what came. > Maybe the logs contain some hint to why dnf's download is so slow. I did not find anything in particular but dnf seems to be very frugal with providing an information. I noticed "extra" files rawhide-filenames.solvx, rawhide.solv and @System.solv together worth around some 47 Megs. Just FYI - my rawhide system is behind a resonably fast, at least on a download side, "home" cable connection but this is definitely not a T1 link. Usually "fast enough" although mirror responses could definitely be a factor. Likely my link is somewhat better than what would be "typical" for a "home connection" in North America. (In reply to Michael Schröder from comment #2) > "Decompression" takes about 1 sec, so that can't make the difference here. > This must be some download issue, maybe dnf picked a slow mirror or > something like that. Michal, do you get that kind of slowness all the time? > Maybe the logs contain some hint to why dnf's download is so slow. by 'decompressing' I meant 'processing', i.e. the time that libsolv is doing the heavy lifting going through xmls and building repodata. interleaving this with the downloads should give some nice speedups. |