sks-devel
[Top][All Lists]
Advanced

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

Re: [Sks-devel] wserver_timeout value causing cascading failure?


From: Jonathon Weiss
Subject: Re: [Sks-devel] wserver_timeout value causing cascading failure?
Date: Fri, 05 May 2017 12:16:03 -0400

Kristian Fiskerstrand <address@hidden> wrote:

> On 04/24/2017 09:33 PM, Jonathon Weiss wrote:
> > Daniel,
> > 
> > I'm pulling your questions into this thread, which I started before
> > seeing your mail:
> > 
> > For reference, I can download this key without a problem.  While I'm
> > topologically closer to pgp.mit.edu than you are, I believe the 1s
> > timeout should only count the time passing the info to Apache, not all
> > the way back to you (but please correct me if you think I'm wrong here).
> > If it is, in fact, taking more than 1s to transfer extremely large keys
> > from SKS to Apache, then I'm somewhat between a rock and a hard place
> > here.  If you go back and try again now, are you still seeing the
> > problem?
> 
> Fwiw, I'm still seeing it.

I've tested a number of compromise configurations.  I'm not sure I've
resolved the cascading failure (time will tell) but I was wondering, if
I've solved the timeout problem on large keys.  Could you re-test?


> > As noted, I dropped this timeout form 4s to 1s last week to deal with
> > the cascading failure described below.
> > 
> > The reverse proxy is Apache, but it is SKS' wserver_timeout that is set
> > to 1s.  
> > 
> > Any thoughts and advice would be welcome here.  I have a couple, but
> > they are either of dubious effectiveness, or relatively drastic / much
> > slower to implement.
> > 
> 
> One thing that springs to mind is multiple instances of SKS behind the
> reverse proxy to distribute the load (I run two instances myself - and
> that is for lesser load). Would just need separate key port and do local
> reconciliation only between them necessary , can make sure stats page
> (?op=stats) only reaches the primary so it exposes the external peers on
> the reverse proxy.

That was my slower to implement thought.  Can you explain your
configuration in a little more detail?  Do I understand correctly that
you're running multiple SKS instances on the same machine?  Each with
their own copy of the DB?  Is there any concern about polluting
https://sks-keyservers.net/status/ ?  I guess all these same questions
apply if you have them on seperate VMs rather than the same machine.

        Jonathon

        Jonathon Weiss <address@hidden>
        MIT/IS&T/Infrastructure Design & Engineering
        Cloud Platforms (Server Operations)



reply via email to

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