Comment 26 for bug 651482

> We're 2/3 times faster with the new yum version but what is really slow is the
> package download/install/remove process. It's sequential if I'm not wrong.

 Ok, yeh. I hadn't realized the yum working parts was so fast already ... was the first test with 3.2.8 or 3.0.l?

 Post depsolving there's work we can do in yum, but I'd guess that most of the work actually needs to be done in rpm. Yum stages are roughly:

1. init - read configs. etc.

2. Run command
  . Possibly download any metadata

3. If command is doing install/remove/update/etc. do a depsolving run
  . Possibly download any metadata

4. Do package downloads
  . We basically do "for pkg in pkgs: download(pkg)"
  . This is also not non-piplined, so each pkg add the latency of the request response.

5. Call "run rpm transaction", this is all inside rpm.

...AIUI from your last post you are getting to #4 in ~2m, and then taking over 3hrs for #4 and #5.
 From yum itself we have no control over #5, although Panu ffesti etc. are working on speeding it up ... but I'd imagine that's going to be a RHEL6 thing.
 We have #4 on the TODO list, to make it do parallel/piplined downloading etc. ... but I don't think we can guarantee that for RHEL5 (part of the process is changing to use curl/pycurl as the backend instead of urllib/httplib).

 We also have on the TODO list to split a large transaction into N smaller ones, and then run each (serially at first, but parallelizing some of it might be possible). This _might_ help you, and we can likely get this into 5.5.

 Looking at BZ 71184 the only thing that looks relevant to yum is the parallel/pipelined download.