[MEDIUM] limit the number of events returned by *poll*
By default, epoll/kqueue used to return as many events as possible.
This could sometimes cause huge latencies (latencies of up to 400 ms
have been observed with many thousands of fds at once). Limiting the
number of events returned also reduces the latency by avoiding too
many blind processing. The value is set to 200 by default and can be
changed in the global section using the tune.maxpollevents parameter.
diff --git a/doc/haproxy-en.txt b/doc/haproxy-en.txt
index 865bf8e..73372e3 100644
--- a/doc/haproxy-en.txt
+++ b/doc/haproxy-en.txt
@@ -128,6 +128,7 @@
- pidfile <file>
- ulimit-n <number>
- stats
+ - tune.maxpollevents <number>
1.1) Event logging
@@ -338,6 +339,12 @@
Version 1.3.9 introduced kqueue() for FreeBSD/OpenBSD, and speculative epoll()
which consists in trying to perform I/O before queuing the events via syscalls.
+In order to optimize latency, it is now possible to limit the number of events
+returned by a single call to poll. The limit is fixed to 200 by default. If a
+smaller latency is seeked, it may be useful to reduce this value by using the
+'tune.maxpollevents' parameter in the 'global' section. Increasing it will
+slightly save CPU cycles in presence of large number of connections.
+
Haproxy will use kqueue() or speculative epoll() when available, then epoll(),
and will fall back to poll(), then to select(). However, if for any reason you
need to disable epoll() or poll() (eg. because of a bug or just to compare
@@ -351,6 +358,7 @@
# use only select()
noepoll
nopoll
+ tune.maxpollevents 100
Note :
------
diff --git a/doc/haproxy-fr.txt b/doc/haproxy-fr.txt
index 63ac9a4..ec74611 100644
--- a/doc/haproxy-fr.txt
+++ b/doc/haproxy-fr.txt
@@ -134,6 +134,7 @@
- quiet
- pidfile <fichier>
- ulimit-n <nombre>
+ - tune.maxpollevents <nombre>
1.1) Journalisation des événements
@@ -362,6 +363,13 @@
les opérations d'entrées/sorties avant de chaîner les événements par les appels
système.
+Afin d'optimiser la latence, il est désormais possible de limiter le nombre
+d'événements remontés à chaque appel. La limite par défaut est fixée à 200. Si
+une latence plus petite est recherchée, il peut être justifié d'abaisser cette
+limite par l'utilisation du paramètre 'tune.maxpollevents' dans la section
+'global'. L'augmenter permettra d'économiser un peu le processeur en présence
+de très grands nombres de connexions simultanées.
+
Haproxy utilisera kqueue() ou speculative epoll() lorsque ce sera disponible,
puis epoll(), et se repliera sur poll(), puis en dernier lieu sur select().
Cependant, si pour une raison quelconque il s'avérait nécessaire de désactiver
@@ -375,6 +383,7 @@
# utiliser seulement select()
noepoll
nopoll
+ tune.maxpollevents 100
Remarque :
----------