sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] Tuning


From: Daniel Kahn Gillmor
Subject: Re: [Sks-devel] Tuning
Date: Tue, 11 Feb 2014 14:19:36 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0

On 02/11/2014 01:58 PM, Benny Baumann wrote:
> Am 11.02.2014 16:59, schrieb Kristian Fiskerstrand:
>> Unless you run it in a clustered setup where the different members
>> calculate it on different times and the frontend passes the request on
>> before timeout :p
>
> Its almost instantly for my maschine ...

what is almost instantly, Benny?  Are you saying that the stats
calculation returns almost instantly?  If so, i wonder why there is such
a variation.  How much RAM is available for your machine?  what other
contention do you have for disk I/O?  What kind of disks are you using?

On a pretty decent machine (zimmermann.mayfirst.org), i'm seeing the
following duration in the logs:

2014-02-11 19:17:17 Calculating DB stats
2014-02-11 19:17:49 Done calculating DB stats

so that's over half a minute of blocked access.

> IMHO better include a line "updated last at $TIME taking $DURATION seconds.

I like this proposal.

> Given most servers update their stats at different times and the number
> of keys you are allowed to lag behind being quite small it's more an
> issue of the stats misrepresenting a keyserver which would actually be
> just fine. Either you would need to update the stats for the pool just
> once a day OR update stats on the individual servers more frequently so
> information isn't lagging behind. 

I'm not sure what you mean "update the stats for the pool".  Do you mean
"update the key size limit" or "check on the stats reported by each
keyserver" or something else?

> I'd advocate for the second option to
> update the stats on the various servers more often as this should reduce
> the fluctuation due to outdated stats pretty good.

If the cost of stats generation was close to zero, i'd agree with you.
But that's not what it looks like to me.   If stats generation is
expensive (and blocking), then increasing the regular frequency of stats
generation would mean more frequent failures of systems already in the
pool (since they don't have a way to remove themselves from the pool
during the time they are generating stats).

        --dkg

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]