Lots of collected data and observations aggregated into a single commit so as not to lose them. Some parts below come from several commit messages and are incremental. Add captures and analysis of intel 14900 where it's not easy to draw the line between the desired P and E cores. The 14900 raises some questions (imagine a dual-die variant in multi-socket). That's the start of an algorithmic distribution of performance cores into thread groups. cpu-map currently conflicts a lot with the choices after auto-detection but it doesn't have to. The problem is the inability to configure the threads for the whole process like taskset does. By offering this ability we can also start to designate groups of CPUs symbolically (package, die, ccx, cores, smt). It can also be useful to exploit the info from cpuinfo that is not available in /sys, such as the model number. At least on arm, higher numbers indicate bigger cores and can be useful to distinguish cores inside a cluster. It will not indicate big vs medium ones of the same type (e.g. a78 3.0 vs 2.4 GHz) but can still be effective at identifying the efficient ones. In short, infos such as cluster ID not always reliable, and are local to the package. die_id as well. die number is not reported here but should definitely be used, as a higher priority than L3. We're still missing a discriminant between the l3 and cluster number in order to address heterogenous CPUs (e.g. intel 14900), though in terms of locality that's currently done correctly. CPU selection is also a full topic, and some thoughts were noted regarding sorting by perf vs locality so as never to mix inter- socket CPUs due to sorting. The proposed cpu-selection cannot work as-is, because it acts both on restriction and preference, and these two are not actions but a sequence. First restrictions must be enforced, and second the remaining CPUs are sorted according to the preferred criterion, and a number of threads are selected. Currently we refine the OS-exposed cluster number but it's not correct as we can end up with something poorly numbered. We need to respect the LLC in any case so let's explain the approach.
HAProxy
HAProxy is a free, very fast and reliable reverse-proxy offering high availability, load balancing, and proxying for TCP and HTTP-based applications.
Installation
The INSTALL file describes how to build HAProxy. A list of packages is also available on the wiki.
Getting help
The discourse and the mailing-list are available for questions or configuration assistance. You can also use the slack or IRC channel. Please don't use the issue tracker for these.
The issue tracker is only for bug reports or feature requests.
Documentation
The HAProxy documentation has been split into a number of different files for ease of use. It is available in text format as well as HTML. The wiki is also meant to replace the old architecture guide.
Please refer to the following files depending on what you're looking for:
- INSTALL for instructions on how to build and install HAProxy
- BRANCHES to understand the project's life cycle and what version to use
- LICENSE for the project's license
- CONTRIBUTING for the process to follow to submit contributions
The more detailed documentation is located into the doc/ directory:
- doc/intro.txt for a quick introduction on HAProxy
- doc/configuration.txt for the configuration's reference manual
- doc/lua.txt for the Lua's reference manual
- doc/SPOE.txt for how to use the SPOE engine
- doc/network-namespaces.txt for how to use network namespaces under Linux
- doc/management.txt for the management guide
- doc/regression-testing.txt for how to use the regression testing suite
- doc/peers.txt for the peers protocol reference
- doc/coding-style.txt for how to adopt HAProxy's coding style
- doc/internals for developer-specific documentation (not all up to date)
License
HAProxy is licensed under GPL 2 or any later version, the headers under LGPL 2.1. See the LICENSE file for a more detailed explanation.