Date: Fri, 07 Nov 2014 13:29:41 +0100 From: "Ronald Klop" <ronald-lists@klop.ws> To: gmx@ross.cx, petefrench@ingresso.co.uk, stable@freebsd.org Subject: Re: Advice on an odd networking problem Message-ID: <op.xoyfnr2akndu52@ronaldradial.radialsg.local> In-Reply-To: <E1XmiWz-0005sK-Un@dilbert.ingresso.co.uk> References: <E1XmiWz-0005sK-Un@dilbert.ingresso.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 07 Nov 2014 13:20:45 +0100, Pete French <petefrench@ingresso.co.uk> wrote: >> My guess from "https" + "proportion of calls" + "503": >> Maybe you run out of random data for ssl connections. >> Thus nginx waits for more random data, times out, apache times out -> >> 503 ? > > I didnt know it would do that - interesting. But in this case the https > is on the outside only - those calls are succeeding, its the intrenal > ones, which are http only, which are failing. > > -pete. I quote your original story: 'We have 5 machines running webservers - apache24 serving cgi scripts, plyus nginx being used to drive uwsgi with some django/python based code. These are load balanced by pound on a machine which faces the internet. This all works as expected, except that if I modify the cgi-scripts running inside Apache so they make some https calls to the nginx server on 127.0.0.1 then what we see is that pound then stops being able to connect to Apache for a proportion of its calls - its returns 503's.' First you say Apache makes https calls to nginx on 127.0.0.1 and now you say https is on the outside only. I find it hard to discuss if you change the story halfway through. So, what is actually taking to long and results in a 503 from where? You need to figure that out. Regards, Ronald.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.xoyfnr2akndu52>