Benjamin Zeller writes:
New RPM transaction backend for zypper: […] It can be enabled by setting: ZYPP_SINGLE_RPMTRANS=1 in zyppers environment.
I've been updating to Tumbleweed machines with this backend for some time and it works really well.
New zypper HTTP backend: Another project we have been working on is parallelizing downloads, for this a new async downloader backend was implemented.
This on the other hand has been problematic. The backend often choses mirrors that are extremely slow (on the other side of the globe or something that seems to be feeding its upload through a DSL line) and just won't stop using these. The most common symptom is that the download of a large file start off at full wire speed until it's somewhere in the 80% region and then drops off to modem speeds until finally all bits have arrived. If one of the servers of a multi-chunk download is a lot slower than the others, that download should be retried elsewhere.
While it currently won't have massive impact on performance due to the frontend code not requesting files asynchronously, it will do some additional mirror rating and as soon as we update the frontend code will bring more benefits.
At least a download-only dup should be able to fire off the downloads of multiple files in parallel. This is quite well supported in libcurl (you don't need multiple threads for that). If you complete the downloads in issue order, the output could be kept the way it appears today with the synchronous backend (but you wouldn't see the progress on the downloads that are started after the current front-of-queue one).