From 84cd05239d27b4a3de9c389da5ee8c2d1c8ec841 Mon Sep 17 00:00:00 2001 From: Colin Watson Date: Thu, 31 Mar 2016 00:25:41 +0100 Subject: [PATCH] clarify timings --- content/re-signing-ppas.md | 31 ++++++++++++++++--------------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/content/re-signing-ppas.md b/content/re-signing-ppas.md index 2de28e1a..15f3ee4e 100644 --- a/content/re-signing-ppas.md +++ b/content/re-signing-ppas.md @@ -31,16 +31,16 @@ imitating this.) After getting that in place, any change to a suite in a PPA will result in it being re-signed with SHA-512, which is good as far as it goes, but we also want to re-sign PPAs that haven't been modified. Launchpad hosts more -than 50000 PPAs, though, a significant percentage of which include packages -for sufficiently recent Ubuntu releases that we'd want to re-sign them for -this. We can't expect everyone to push new uploads, and we need to run this -through at least some part of our usual publication machinery rather than -just writing a hacky shell script to do the job (which would have no idea -which keys to sign with, to start with); but forcing full reprocessing of -all those PPAs would take a prohibitively long time, and at the moment we -need to interrupt normal PPA publication to do this kind of work. I -therefore had to spend some quality time working out how to make things go -fast enough. +than 50000 active PPAs, though, a significant percentage of which include +packages for sufficiently recent Ubuntu releases that we'd want to re-sign +them for this. We can't expect everyone to push new uploads, and we need to +run this through at least some part of our usual publication machinery +rather than just writing a hacky shell script to do the job (which would +have no idea which keys to sign with, to start with); but forcing full +reprocessing of all those PPAs would take a prohibitively long time, and at +the moment we need to interrupt normal PPA publication to do this kind of +work. I therefore had to spend some quality time working out how to make +things go fast enough. The first couple of changes ([1](https://code.launchpad.net/~cjwatson/launchpad/publish-distro-careful-release/+merge/289401), @@ -142,11 +142,12 @@ gets the per-archive time down to about a quarter of a second on our staging system, about eight times faster than where we started. Using this, we've now re-signed all xenial `Release` files in PPAs using -SHA-512 digests. On production, this took about 80 minutes for 1761 -affected archives. This is over two seconds per modified archive, but in -practice most of the time appears to have been spent skipping over -unmodified archives; even a few hundredths of a second per archive adds up -quickly there. There's certainly still room for speeding this up a bit. +SHA-512 digests. On production, this took about 80 minutes to iterate over +around 70000 archives, of which 1761 were modified. Most of the time +appears to have been spent skipping over unmodified archives; even a few +hundredths of a second per archive adds up quickly there. The remaining +time comes out to around 0.4 seconds per modified archive. There's +certainly still room for speeding this up a bit. We wouldn't want to do this procedure every day, but it's acceptable for occasional tasks like this. I expect that we'll similarly re-sign wily, -- 2.30.2