Comment 4 for bug 963420

When I opened this bug, I didn't realize that the http traffic to that same url was roughly equivalent in precise and lucid. So, I thought that it must have been the virtio drivers that have regressed. However, realizing that, the likely issue would seem to be higher in the stack.

Doing another test, I actually get between 10 and 12M/S in both lucid and precise using curl, rather than wget.

This changes my suspicion to:
 * precise wget is regressed in performance between lucid and precise on https traffic.

As a result, for the moment I'm going to tag the kernel thread as invalid.

One point of data, in lucid, watching 'top' while the https is happening I see wget basically eating 90+% of one cpu. in precise that number is significantly lower, it only ends up getting to 50% or so.

Also, precise:
 $ time wget -q https://cloud-images.ubuntu.com/precise/current/precise-server-cloudimg-amd64-disk1.img -O /dev/null
 real 0m18.253s
 user 0m9.745s
 sys 0m1.796s

Lucid:
$ time wget -q https://cloud-images.ubuntu.com/precise/current/precise-server-cloudimg-amd64-disk1.img -O /dev/null
real 0m4.195s
user 0m3.110s
sys 0m0.590s

So, a significantly larger amount of time (3X) was spent in user precise wget compared to lucid.
The wget version in lucid is 1.12-1.1ubuntu2.1, in precise 1.13.4-2ubuntu1 .

I guess the next thing to do is to try precise wget on lucid or vice-versa and see what the difference is.