9dd56da730
It was noticed in haproxy that in certain extreme cases, a write lock subject to EBO may fail for a very long time in front of a large set of readers constantly trying to upgrade to the S state. The reason is that among many readers, one will succeed in its upgrade, and this situation can last for a very long time with many readers upgrading in turn, while the writer waits longer and longer before trying again. Here we're taking a reasonable approach which is that the write lock should have a higher precedence in its attempt to grab the lock. What is done is that instead of fully rolling back in case of conflict with a pure S lock, the writer will only release its read part in order to let the S upgrade to W if needed, and finish its operations. This guarantees no other seek/read/write can enter. Once the conflict is resolved, the writer grabs the read part again and waits for readers to be gone (in practice it could even return without waiting since we know that any possible wanderers would leave or even not be there at all, but it avoids a complicated loop code that wouldn't improve the practical situation but inflate the code). Thanks to this change, the maximum write lock latency on a 48 threads AMD with aheavily loaded scheduler went down from 256 to 64 ms, and the number of occurrences of 32ms or more was divided by 300, while all occurrences of 1ms or less were multiplied by up to 3 (3 for the 4-16ns cases). This is plock commit b6a28366d156812f59c91346edc2eab6374a5ebd. |
||
|---|---|---|
| .github | ||
| addons | ||
| admin | ||
| dev | ||
| doc | ||
| examples | ||
| include | ||
| reg-tests | ||
| scripts | ||
| src | ||
| tests | ||
| .cirrus.yml | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| .travis.yml | ||
| BRANCHES | ||
| BSDmakefile | ||
| CHANGELOG | ||
| CONTRIBUTING | ||
| INSTALL | ||
| LICENSE | ||
| MAINTAINERS | ||
| Makefile | ||
| README.md | ||
| SUBVERS | ||
| VERDATE | ||
| VERSION | ||
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.