Hi Andy,
On Tue, May 27, 2014 at 06:00:37PM +0100, Andrew Phillips wrote:
> Something I overlooked replying to on this thread;
>
> > BTW, I remember you said that you fixed the busy loop by disabling the
> > FD in the speculative event cache, but do you remember how you re-enable
> > it ? Eg, if
Something I overlooked replying to on this thread;
> BTW, I remember you said that you fixed the busy loop by disabling the
> FD in the speculative event cache, but do you remember how you re-enable
> it ? Eg, if all other processes have accepted some connections, your
> first process will have to
Hi Andy,
On Sun, May 18, 2014 at 03:16:34PM +0100, Andrew Phillips wrote:
> Willy,
>
> Thanks for the response. I wrote the reply as I read through, so it's
> interesting to see that we've pursued similar lines of thought about how
> to solve this problem.
>
> I think our workload is very dif
Willy,
Thanks for the response. I wrote the reply as I read through, so it's
interesting to see that we've pursued similar lines of thought about how
to solve this problem.
I think our workload is very different from 'normal'. We have several
quite long lived connections, with a modest accept
Hi James,
On Tue, May 13, 2014 at 06:00:13PM +0100, James Hogarth wrote:
> Hi Willy,
>
> Please see the response from our Head of Systems below.
Thank you. For ease of discussions, I'm copying him. Andy, please tell me
if this is not appropriate.
> On a side note our initial investigations see
Hi James,
On Thu, May 08, 2014 at 08:58:59PM +0100, James Hogarth wrote:
> On 2 May 2014 20:10, Willy Tarreau wrote:
>
> > You're welcome. I really want to release 1.5-final ASAP, but at least
> > with everything in place so that we can safely fix the minor remaining
> > annoyances. So if we ide
Hi James,
On Fri, May 02, 2014 at 07:23:21PM +0100, James Hogarth wrote:
> We've done quite a bit of work on this internally recently to provide SSL
> multiprocess with sane load balancing.
>
> There's a couple of small edge cases we've got left then we were intending
> to push it up for comments
Great, we'd love to see that.
And thanks for the other SSL performance trick. We might be able to
make that and some SSL cache tuning work for us, as well.
On Fri, May 2, 2014 at 12:23 PM, James Hogarth wrote:
>
> On 2 May 2014 19:02, "Willy Tarreau" wrote:
>>
>> On Fri, May 02, 2014 at 10:59:0
On 2 May 2014 19:02, "Willy Tarreau" wrote:
>
> On Fri, May 02, 2014 at 10:59:00AM -0700, Bryan Talbot wrote:
> > It sounds like that Jeff ran out of CPU for SSL terminations and that
could
> > be addressed as described by Willy here
> >
> > https://www.mail-archive.com/haproxy@formilux.org/msg131
On Fri, May 02, 2014 at 10:59:00AM -0700, Bryan Talbot wrote:
> It sounds like that Jeff ran out of CPU for SSL terminations and that could
> be addressed as described by Willy here
>
> https://www.mail-archive.com/haproxy@formilux.org/msg13104.html
>
> and allow him to stay with a single-process
It sounds like that Jeff ran out of CPU for SSL terminations and that could
be addressed as described by Willy here
https://www.mail-archive.com/haproxy@formilux.org/msg13104.html
and allow him to stay with a single-process stick table for the actual load
balancing.
-Bryan
On Fri, May 2, 201
hi,
On Fri, May 02, 2014 at 11:11:39AM -0600, Jeff Zellner wrote:
> Well, I thought wrong -- I see that peered sticky tables absolutely
> don't work with multiple processes, and sticky rules give a warning.
>
> Would that be a feature on the roadmap? I can see that it's probably
> pretty non-triv
Well, I thought wrong -- I see that peered sticky tables absolutely
don't work with multiple processes, and sticky rules give a warning.
Would that be a feature on the roadmap? I can see that it's probably
pretty non-trivial -- but would be super useful, at least for us.
On Fri, May 2, 2014 at 9:
Hey all,
We'd like to start terminating SSL (so that we can balance on url
parameters, primarily) on one of our busiest load balancer clusters.
Unfortunately, running with nbproc=1 our peak traffic causes us to
just-barely max out a CPU core -- just enough to severely degrade
latency/performance.
14 matches
Mail list logo
