sks-devel
[Top][All Lists]
Advanced

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

Re: [Sks-devel] Tuning


From: Benny Baumann
Subject: Re: [Sks-devel] Tuning
Date: Tue, 11 Feb 2014 19:58:29 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi,

Am 11.02.2014 16:59, schrieb Kristian Fiskerstrand:
> On 02/11/2014 04:53 PM, Daniel Kahn Gillmor wrote:
> > On 02/11/2014 10:48 AM, Kristian Fiskerstrand wrote:
> >> By default stats are updated once a day, for more than this you
> >> need to send a USR2-signal to sks.
>
> > In particular, you need to send USR2 to "sks db", not "sks recon".
> > And note that while "sks db" is calculating stats, it cannot serve
> > HKP requests.  It can take several minutes or more to calculate the
> > stats (depending on the work pattern of the machine), so during
> > that time, your keyserver will not be responsive.
>
>
> 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 ...
>
> I wonder if it would be interesting to record the update stats times
> on the servers and use this for exclusion in the pools around the
> update time somehow. Are people experiencing any difference to the
IMHO better include a line "updated last at $TIME taking $DURATION seconds.
> responsiveness of the pool after switching to requirement of rprox?
> And is it worthwhile to add some kind of stats update detection, or is
> this issue so minor that it would only add unnecessary complexity?
I think most servers in the pool should cope just fine with it.
>
> One thing I've noticed is that the number of servers in the pools
> themselves fluctuate throughout the day if there are larger additions
> in number of keys, as the servers updating once a day gets dropped for
> missing keys to the dynamic stats. But with the number of servers we
> have today, from a pool perspective this is perfectly OK.
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'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.

Regards,
BenBE.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBCgAGBQJS+nLUAAoJEPHTXLno4S6t7pUP/jN/ZJizNx6Wr6ZI4EBMq7PV
Jn++0nu11l62oPfK/rSgnUOrzYB1VXOFveeyDK607fu4p7kjeMCYQFx4MxuOqli3
tn+ZEGBhTv6G9TFuLKQuc+WRFcLjz2SCbfCIeNNzB0yizCFs1fJ+iY7zaYSjVwjA
pzVytnASPZVkgPgxeTLsZNfQ/gHq1iRlqgw3HDRh4ApjW1Y43DoI2rTnCmKI1kpY
PjGjJWeKkn7mDxLZr8qx/2Icn3RQbkc4jAAgHEELcNpA4InDu3HOexmSBwRFuUoU
FnkEx0YPzoosWoCUMlw1zY9Yn9ttF2WMcbFS3hsxBly83zZ/sDA7ssXal3O/KGlO
8ZNenpJFhy4akIDAC8nuGznhHqZu5FDKU/fKjO3oMUJjhBEW7bdl1NE69LIFHYK6
3kcWnESLpFR5vD9KfA3BuidJqtAza3hZojcltMgerKx3wZ2zLV4Me+xH78jcEFz6
cGMxxZnTRmvr75ZqGG+kyg3EyIMKlnB3TOFg1PqTdmsGMep79+5Die58wrDULRxh
alMPfKboSM1RJ/R13YMIAYCWe+yJcNIHKV2zXzeVxBXvbPv8pt0FaPlFC3SVd4Ma
/jYm3HoiDVmvxQZ9Gx72I3okt9SBBFVYk3p4QqdnMC5fIkiWyY1fJ+hJxWdpHrpr
Eg7fgMTQGeIn0AoaIIKZ
=evzP
-----END PGP SIGNATURE-----




reply via email to

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