Re: haproxy and solarflare onload

Hi Elias, On Tue, Dec 19, 2017 at 02:23:21PM +0100, Elias Abacioglu wrote: > Hi, > > I recently bought a solarflare NIC with (ScaleOut) Onload / OpenOnload to > test it with HAproxy. > > Have anyone tried running haproxy with solarflare onload functions? > > After I started haproxy with

Re: [PATCH 1/2] Fix compiler warning in iprange.c

On Fri, Dec 15, 2017 at 10:21:29AM -0600, Ryan O'Hara wrote: > The declaration of main() in iprange.c did not specify a type, causing > a compiler warning [-Wimplicit-int]. This patch simply declares main() > to be type 'int' and calls exit(0) at the end of the function. Both patches applied,

Re: [PATCH] BUG: NetScaler CIP handling is incorrect

Great, thank you guys! Best regards, Andreas On Wed, Dec 20, 2017 at 7:06 AM, Willy Tarreau wrote: > On Tue, Dec 19, 2017 at 11:10:58PM +, Bertrand Jacquin wrote: > > Hi Andreas and Willy, > > > > Please find attached a patch serie adding support for both legacy and > >

Re: haproxy and solarflare onload

Hi, Yes on the LD_PRELOAD. Yes, I have one node running with Solarflare SFN8522 2p 10Gbit/s currently without Onload enabled. it has 17.5K http_request_rate and ~26% server interrupts on core 0 and 1 where the NIC IRQ is bound to. And I have a similar node with Intel X710 2p 10Gbit/s. It has

Re: haproxy and solarflare onload

Hi Elias, I'm currently preparing a test setup including a SFN8522 + onload. How did you measure it? When did those errors (drops/discard?) appear, during a test or some real traffic? The first thing I did is updating the driver + firmware. Is both up2date in your case? I haven't measured /

Re: 1.8.1 Segfault + slowdown

update: we've disabled h2 on 1.8, and everything is running as expected again. haproxy does not degrade performance anymore nor does it segfault. so it issues seem to be related to the h2 Med venlig hilsen *Peter Lindegaard Hansen* *Softwareudvikler / Partner* Telefon: +45 96 500 300 |

Re: haproxy and solarflare onload

On Wed, Dec 20, 2017 at 3:27 PM, Christian Ruppert wrote: > Oh, btw, I'm just reading that onload documentation. > > > Filters > Filters are used to deliver packets received from the wire to the > appropriate > application. When filters are exhausted it is not possible to create

Re: haproxy and solarflare onload

On Wed, Dec 20, 2017 at 2:10 PM, Willy Tarreau wrote: > On Wed, Dec 20, 2017 at 11:48:27AM +0100, Elias Abacioglu wrote: > > Yes, I have one node running with Solarflare SFN8522 2p 10Gbit/s > currently > > without Onload enabled. > > it has 17.5K http_request_rate and ~26% server

Re: haproxy and solarflare onload

On Wed, Dec 20, 2017 at 1:11 PM, Christian Ruppert wrote: > Hi Elias, > > I'm currently preparing a test setup including a SFN8522 + onload. > How did you measure it? When did those errors (drops/discard?) appear, > during a test or some real traffic? > The first thing I did is

Re: haproxy and solarflare onload

> > Apparently I'm not graphing conn_rate (i need to add it, but I have no > values now), cause we're also sending all SSL traffic to other nodes using > TCP load balancing. > Update: I'm at around 7,7k connection rate.

Re: haproxy and solarflare onload

On Wed, Dec 20, 2017 at 11:48:27AM +0100, Elias Abacioglu wrote: > Yes, I have one node running with Solarflare SFN8522 2p 10Gbit/s currently > without Onload enabled. > it has 17.5K http_request_rate and ~26% server interrupts on core 0 and 1 > where the NIC IRQ is bound to. > > And I have a

Issue after upgrade from 1.7 to 1.8 related with active sessions

Hello, After upgrade from 1.7.4 to 1.8.1, basically with the end of mail conf snippet, the sessions started to grow, as example: 1.7.4: Active sessions: ~161 Active sessions rate: ~425 1.8.1: Active sessions: ~6700 Active sessions rate: ~350 Looking into the linux (3.16.7) server, there are a

Re: haproxy and solarflare onload

Oh, btw, I'm just reading that onload documentation. Filters Filters are used to deliver packets received from the wire to the appropriate application. When filters are exhausted it is not possible to create new accelerated sockets. The general recommendation is that applications do not

Re: Issue after upgrade from 1.7 to 1.8 related with active sessions

Hello Ricardo, On Wed, Dec 20, 2017 at 05:00:33PM +0100, Ricardo Fraile wrote: > Hello, > > After upgrade from 1.7.4 to 1.8.1, basically with the end of mail conf > snippet, the sessions started to grow, as example: > > 1.7.4: > Active sessions: ~161 > Active sessions rate: ~425 > > 1.8.1: >

Traffic delivered to disabled server when cookie persistence is enabled after upgrading to 1.8.1

When cookie persistence is used, it seems that the status of the servers in the backend is ignored in v1.8.1. I try marking as MAINT a backend server for which my browser has been given a cookie but subsequent requests still go to that server (as verified in the stats). The same issue happens when

Re: Traffic delivered to disabled server when cookie persistence is enabled after upgrading to 1.8.1

Hi Greg You say traffic still goes to the real server when in MAINT mode, Assuming you mean DRAIN Mode and not HALTED then this is expected. Existing connections still goto a server while DRAINING but no new connections will get there. If the real server is HALTED then no traffic gets to it.

Re: Traffic delivered to disabled server when cookie persistence is enabled after upgrading to 1.8.1

Greg its just been pointed out your cookies are wrong, they would usually match your server name. I would change this server server-1-google www.google.com:80 check cookie google server server-2-yahoo www.yahoo.com:80 check cookie yahoo to this server server-1-google www.google.com:80

Re: Traffic delivered to disabled server when cookie persistence is enabled after upgrading to 1.8.1

Hi Andrew, I can’t find any reference to a “HALTED” status in the manual. I’m *not* referring to “DRAIN” though (which I would expect to behave as you describe), I’m referring to "MAINT", i.e. disabling the backend server. Here’s the snippet from the management manual to clarify what I’m

Re: Haproxy SSl Termination performance issue

Op di 19 dec. 2017 om 16:16 schreef hongw...@163.com > Hi, Thierry. > > Thanks again. > > One more question about you talking about, can i just think like this way: > assume we got a 8core cpu, we use 7 of them for ssl termination and one is > for http forward? If it is, is

Re: Traffic delivered to disabled server when cookie persistence is enabled after upgrading to 1.8.1

Hi Greg Apologies I was confused with the terminology we use here, Indeed MAINT should be the same as our HALT feature, Maybe you can share your config and we can see what's wrong? Andruw Smalley Loadbalancer.org Ltd. www.loadbalancer.org +1 888 867 9504 / +44 (0)330 380 1064

Re: Traffic delivered to disabled server when cookie persistence is enabled after upgrading to 1.8.1

Also our cookie line looks as below  cookie SERVERID maxidle 30m maxlife 12h insert nocache indirect Andruw Smalley Loadbalancer.org Ltd. www.loadbalancer.org +1 888 867 9504 / +44 (0)330 380 1064 asmal...@loadbalancer.org Leave a Review | Deployment Guides | Blog On 20 December 2017 at

回复：Haproxy SSl Termination performance issue

Hi, JohanThanks a lotMikeSent from my HuaWei mate9 Phone 原始邮件 主题：Re: Haproxy SSl Termination performance issue发件人：Johan Hendriks 收件人：haproxy@formilux.org,hongw...@163.com抄送：Op di 19 dec. 2017 om 16:16 schreef hongw...@163.com Hi,

Re: Traffic delivered to disabled server when cookie persistence is enabled after upgrading to 1.8.1

Hi Andrew, Thanks for the info but I’m afraid I’m not seeing anything here that would affect the issue I’m seeing, and by the way the docs don’t indicate that the cookie names have to match the server names. That being said, I tried using your settings and am still seeing the issue (see below

Re: Traffic delivered to disabled server when cookie persistence is enabled after upgrading to 1.8.1

Hi Greg, Le 20/12/2017 à 22:42, Greg Nolle a écrit : Hi Andrew, Thanks for the info but I’m afraid I’m not seeing anything here that would affect the issue I’m seeing, and by the way the docs don’t indicate that the cookie names have to match the server names. First, don't worry about the

Re: Traffic delivered to disabled server when cookie persistence is enabled after upgrading to 1.8.1

On Thu, Dec 21, 2017 at 12:04:11AM +0100, Cyril Bonté wrote: > Hi Greg, > > Le 20/12/2017 à 22:42, Greg Nolle a écrit : > > Hi Andrew, > > > > Thanks for the info but I'm afraid I'm not seeing anything here that > > would affect the issue I'm seeing, and by the way the docs don't > > indicate

Re: Quick update on pending HTTP/2 issues

Hi again guys, so another quick update on the subject : - the currently known POST issues have been resolved a few days ago, requiring a significant number of changes which make the code better anyway so it was not bad in the end ; - the abortonclose case has been solved as well. The