Re: Anyone heard about DPDK?
Nowadays most VNF (virtual network function) in the telco operators are built around DPDK. Not demos, most 5G will be like that. 4G is migrating as we speak on this new architecture. There isn't any TCP stack built-it but the libraries can be used to build one. VPP has integrated DPDK in this way. Linux network stack is not designed to managed millions of packets per second, DPDK bypass it completely offloading everything in userspace. The beauty is that also the physical nic drivers are in userspace using specific DPDK drivers. Linux networking stack works in interrupt mode, DPDK is in polling mode, basically with a while true. >From F5 at the dpdk summit as a relevant reference to what HAProxy does. https://dpdksummitnorthamerica2018.sched.com/event/IhiF/dpdk-on-f5-big-ip-virtual-adcs-brent-blood-f5-networks https://www.youtube.com/watch?v=6zu81p3oTeo Regards, Federico On Tue, 12 Feb 2019 at 11:08, Julien Laffaye wrote: > Something like http://seastar.io/ or https://fd.io/ ? :) > > On Mon, Feb 11, 2019 at 11:25 AM Baptiste wrote: > >> Hi, >> >> HAProxy requires a TCP stack below it. DPDK itself is not enough. >> >> Baptiste >> >>>
Re: info defaults maxconn
Thanks a lot, and sorry for my misinterpretation :-) Cheers, Federico On Wed, 6 Feb 2019 at 14:59, Aleksandar Lazic wrote: > Hi Federico. > > Am 06.02.2019 um 15:33 schrieb Federico Iezzi: > > Hey there, > > > > Maybe this is gonna be a very simple answer. > > In HAProxy 1.5.18 seems that the defaults maxconn have a global > influence and not per backend one. > > > > In my case I have global maxconn at 5120001, while defaults at 256. What > I'm trying to achieve is to set for all my backends the > same maxconn without having the parameter everywhere. > > > > Testing it, I basically saturated the 256 connections right away and > everything was queued. But that happened globally and not on a > per-backend basis. > > > > Is that expected? > > Yes, AFAIK. > > Default/FE/Listen maxconn > https://cbonte.github.io/haproxy-dconv/1.5/configuration.html#4-maxconn > > ``` > Fix the maximum number of concurrent connections on a frontend > ... > ``` > > Backend maxconn is default 0 > https://cbonte.github.io/haproxy-dconv/1.5/configuration.html#5.2-maxconn > > > ``` > ... > The default value is "0" which means unlimited. > ... > ``` > > Thanks! > > Federico > > Regards > Aleks >
info defaults maxconn
Hey there, Maybe this is gonna be a very simple answer. In HAProxy 1.5.18 seems that the defaults maxconn have a global influence and not per backend one. In my case I have global maxconn at 5120001, while defaults at 256. What I'm trying to achieve is to set for all my backends the same maxconn without having the parameter everywhere. Testing it, I basically saturated the 256 connections right away and everything was queued. But that happened globally and not on a per-backend basis. Is that expected? Thanks! Federico
TLS HAProxy Scalability
Hi there, Recently I didn't have time to follow up the HAProxy 1.7 development and I would like to understand if you have find a way for the TLS handshakes performance sort of issue. Some month ago someone started a discussion on the mailing list and Willy thought that a multi-threaded approach would be better than the current one based on process. I just would like to understand the current status :-) Thanks a lot! Federico
Re: [ANNOUNCE] haproxy-1.5.0
Hey Willy! Many many congratulations Il giorno 19/giu/2014, alle ore 21:54, Willy Tarreau w...@1wt.eu ha scritto: Hi everyone, The list has been unusually silent today, just as if everyone was waiting for something to happen :-) Today is a great day, the reward of 4 years of hard work. I'm announcing the release of HAProxy 1.5.0. For people who don't follow the development versions, here are the most noticeable features that 1.5 brings over 1.4 : - native SSL support on both sides with SNI/NPN/ALPN and OCSP stapling. - IPv6 and UNIX sockets are supported everywhere - end-to-end HTTP keep-alive for better support of NTLM and improved efficiency in static farms - HTTP/1.1 response compression (deflate, gzip) to save bandwidth - PROXY protocol versions 1 and 2 on both sides - data sampling on everything in request or response, including payload - ACLs can use any matching method with any input sample - maps and dynamic ACLs updatable from the CLI - stick-tables support counters to track activity on any input sample - custom format for logs, unique-id, header rewriting, and redirects - improved health checks (SSL, scripted TCP, check agent, ...) - much more scalable configuration supports hundreds of thousands of backends and certificates without sweating Since dev26, a few bugs were fixed, and some low-importance things were integrated. Basic OCSP stapling support from Dirkjan and Emeric was finally merged. Sasha's header replace actions were merged as well. I've added a few more info in the stats page (avg response times) and CSV output (health check status), added support for PROXY v2 on the accept side, and added the capture action on tcp-request in order to log contents such as SNI or payload. Rémi's dh-param was finally integrated. People love numbers, so here are a few : From 1.4.0 to 1.5.0, we had : - 1574 calendar days (4 yr 3 mon) - 26 development versions (one every 2 months on average) - 540 bugs fixed (387 added during 1.5, 153 affecting 1.4 as well) - 2549 commits - 683 unique commit dates (at least this many days worked) - up to 24 commits per day - 69712 lines removed, 122279 lines added - many extremely useful bug reports (too many to list) - 73 code/doc contributors : Adrian Bridgett, Alex Davies, Aman Gupta, Andreas Kohn, Apollon Oikonomopoulos, Arnaud Cornet, Baptiste Assmann, Bertrand Jacquin, Bhaskar Maddala, Conrad Hoffmann, Cyril Bonté, Daniel Schultze, David BERARD, David Cournapeau, David S, David du Colombier, Delta Yeh, Dirkjan Bussink, Dmitry Sivachenko, Emeric Brun, Emmanuel Hocdet, Evan Broder, Finn Arne Gangstad, Gabor Lekeny, Geoff Bucar, Wei Zhao, Guillaume Castagnino, Guillaume de Lafond, Hervé COMMOWICK, Hiroaki Nakamura, James Voth, Jamie Gloudon, Jarno Huuskonen, Joe Williams, Joshua M. Clulow, Julien Vehent, Justin Karneges, Kevin Hester, Kevin Musker, Kristoffer Grönlund, Krzysztof Piotr Oledzki, Lukas Tribus, Marc-Antoine Perennou, Mark Lamourine, Mathieu Trudel, Michael Scherer, Neil Prockter, Nenad Merdanovic, Nick Chalk, Olivier Burgard, Oskar Stolc, Patrick Mézard, Pieter Baauw, Prach Pongpanich, Rauf Kuliyev, Remi Gacogne, Sagi Bashari, Sasha Pachev, Sean Carey, Sergiy Prykhodko, Simon Horman, Simone Gotti, Stathis Voukelatos, Tait Clarridge, Thierry Fournier, Todd Lyons, Vincent Bernat, William Lallemand, William Turner, Willy Tarreau, Yuxans Yao, Yves Lafon. Additionally, we are very thankful to a few organisations who have sponsored the development of certain advanced features which required to dedicate a person or a team for a significant amount of time (I hope I have not missed any) : - HAProxy Technologies (formerly Exceliance) - Loadbalancer.org - StackOverflow - SmartFile - SmugMug - ImageShack Don't forget to offer a beer to your distro packagers who make your life easier. It's hard to list them all, but if you don't build from sources, you're likely running a package made and maintained by one of these people : - debian: Vincent Bernat, Apollon Oikonomopoulos, Prach Pongpanich - Fedora: Ryan O'hara - OpenSuSE: Marcus Rückert - other? just report yourself! And last, I'd like to assign a special mention to our most active mailing list supporters during that period who make the project a reality by off- loading the support task from developers, and kindly help our 800 permanent subscribers on a daily basis, BIG THANKS to you guys : - Baptiste Assmann - Lukas Tribus - Cyril Bonté - Jonathan Matthews - Thomas Heil For the HAProxy development team here in France, it will be time to do some errands and buy some Champagne to celebrate the event :-) Now the practical things. 1.5 now enters in maintenance status and the development continues with 1.6-dev0 which is the exact equivalent of 1.5.0. The links have been updated below. Note the removal of /devel/ for the sources and the
Re: 1.5-dev22 crash with kernel messages, 1.4.18 is fine
Guys we fix these problems using a kernel = 3.8 With Ubuntu 12.04.4 we are using Kernel 3.8 and 3.11 from Canonical official repository with out any issue. With 3.5 and stock 3.2 we had a lot trouble. Regards, Federico Il giorno 27/feb/2014, alle ore 13:01, Sander Klein roe...@roedie.nl ha scritto: Hi, I can confirm that using grsec kernel with haproxy can sometimes be a bit tricky. For instance, 3.2.54 with grsec crashes with me after ~8 hours while 3.2.55 and 3.2.52 with grsec do not. Kernels with grsec just need more testing because their stability can vary. Greets, Sander On 27.02.2014 11:29, Cedric Maion wrote: I agree that it does indeed look like a kernel issue (in the intel eth driver?), however 1.5 is doing something new that triggers this. Any idea of a significant 1.4 - 1.5 change that can affect what is happening in the kernel? This kernel is indeed not the stock Ubuntu kernel, but the default one provided by the hosting company (OVH in that case)... I would really like not having to recompile the kernel and play too much with the production environment (sadly this issue never popped in my dev lab environments). So any haproxy related idea would be very welcome...! On Thu, Feb 27, 2014 at 11:06:38AM +0100, Lukas Tribus wrote: Hi, Just upgraded a production node from 1.4.18 to 1.5-dev22. Ran fine for a couple of minutes then crashed with the following kernel messages: WARNING: at mm/page_alloc.c:2107 __alloc_pages_nodemask+0x1fd/0x790() Hardware name: X9SRE/X9SRE-3F/X9SRi/X9SRi-3F Pid: 23190, comm: haproxy Not tainted 3.2.13-grsec--grs-ipv6-64 #1 Call Trace: [810f1ded] ? __alloc_pages_nodemask+0x1fd/0x790 [81089f3b] warn_slowpath_common+0x7b/0xc0 [81089f95] warn_slowpath_null+0x15/0x20 [810f1ded] __alloc_pages_nodemask+0x1fd/0x790 Thats definitely a kernel issue. Are you building your own kernel? That doesn't look like the default Ubuntu kernel. I would suggest to upgrade your kernel to 3.2.55 (of course use an updated grsec patch as well). If that doesn't fix the issue, try vanilla 3.2.55 (no grsec). If the issue persists, report it upstream (either to lkml/netdev or grsec, depending whether the vanilla 3.2.55 has the issue or not). Regards, Lukas
Re: [ANNOUNCE] haproxy-1.5-dev20
Awesome Willy! Il giorno 16/dic/2013, alle ore 03:41, Willy Tarreau w...@1wt.eu ha scritto: Hi all, here is probably the largest update we ever had, it's composed of 345 patches! Some very difficult changes had to be made and as usual when such changes happen, they take a lot of time due to the multiple attempts at getting them right, and as time goes, people submit features :-) After two weeks spent doing only fixes, I thought it was time to issue dev20. I'm sure I'll forget a large number of things, but the main features of this version include the following points (in merge order) : - optimizations (splicing, polling, etc...) : a few percent CPU could be saved ; - memory : the connections and applets are now allocated only when needed. Additionally, some structures were reorganized to avoid fragmentation on 64-bit systems. In practice, an idle session size has dropped from 1936 bytes to 1296 bytes (-640 bytes, or -33%). - samples : all sample fetch expressions now support a comma-delimited list of converters. This is also true in ACLs, so that it becomes possible to do things like : # convert to lower case and use fast tree indexing acl known_domain hdr(host),lower -f huge-domain-list.lst - a lot of code has been deduplicated in the tracked counters, it's now possible to use sc_foo_bar(1, args) instead of sc1_foo_bar(args). Doing so has simplified the code and makes life of APIs easier. - it's now possible to look up a tracked key from another table. This allows to retrieve multiple counters for the same key. - several hash algorithms are provided, and it is possible to select them per backend. This high quality work was done at Tumblr by Bhaskar Maddala. - agent-checks: this new feature was merged and replaced the lb-agent-chk. Some changes are still planned but feedback is welcome. The goal of this agent is to retrieve soem weight information from a server independantly of the service health. A typical usage would consist in reporting the server's idle percentage as an estimate of the possible weight. This work was done by Simon Horman for Loadbalancer.org. - samples : more automatic conversions between types are supported, making it easier to stick to any parameter. The types are much more dynamic now. Some improvements are still pending. This work was done by Thierry Fournier at Exceliance. - map : a new type of converter appeared : maps. A map matches a key from a file just like ACLs do, and replaces this value with the value associated with the key on the same line of the file. As it is a converter, it can be used in any sample expression. The first usage consists in geolocation, where networks are associated with country codes. Maps may be consulted, deleted, updated and filled from the CLI. Some will probably use this to program actions or emulate ACLs without even reloading a config. This work was also achieved by Thierry Fournier, and reviewed by Cyril Bonté who developped the original Geoip patchset for 1.4 and 1.5. - http-request redirect now supports log-format like expressions, just like http-request add-header. This allows to emit strings extracted from the request (host header, country code from a map, ...). Thierry again here. - checks: tcp-check supports send/expect sequences with strings/regex/binary. Thus it now becomes possible to check unsupported protocols, even binary. This work is from Baptiste Assmann. - keep-alive: the dynamic allocation of the connection and applet in the session now allows to reuse or kill a connection that was previously associated with the session. Thus we now have a very basic support for keep-alive to the servers. There is even an option to relax the load balancing to try to keep the same connection. Right now we don't do any connection sharing so the main use is for static servers and for far remote servers or those which require the broken NTLM auth. That said, the performance tests I have run show an increase from 71000 connections per second to 15 keep-alive requests per second running on one core of a Xeon E5 3.6 GHz. This doubled to 300k requests per second with two cores. I didn't test above, I lacked injection tools :-) One good point is that it will help people assemble haproxy and varnish together with haproxy doing the consistent hash and varnish caching after it. As most of you know, server-side keep-alive is the condition to release 1.5. Now we have it, we'll be able to improve on it but it's basically working. I expect to release 1.5-final around January and mostly focus on chasing bugs till there. So I'd like to set a feature freeze. I know it doesn't mean much considering that we won't stop contribs. But I don't want to merge another large patch set before the release.
