Willy Tarreau f2e8ee2b46 [MEDIUM] reduce risk of event starvation in ev_sepoll
If too many events are set for spec I/O, those ones can starve the
polled events. Experiments show that when polled events starve, they
quickly turn into spec I/O, making the situation even worse. While
we can reduce the number of polled events processed at once, we
cannot do this on speculative events because most of them are new
ones (avg 2/3 new - 1/3 old from experiments).

The solution against this problem relies on those two factors :
  1) one FD registered as a spec event cannot be polled at the same time
  2) even during very high loads, we will almost never be interested in
     simultaneous read and write streaming on the same FD.

The first point implies that during starvation, we will not have more than
half of our FDs in the poll list, otherwise it means there is less than that
in the spec list, implying there is no starvation.

The second point implies that we're statically only interested in half of
the maximum number of file descriptors at once, because we will unlikely
have simultaneous read and writes for a same buffer during long periods.

So, if we make it possible to drain maxsock/2/2 during peak loads, then we
can ensure that there will be no starvation effect. This means that we must
always allocate maxsock/4 events for the poller.

Last, sepoll uses an optimization consisting in reducing the number of calls
to epoll_wait() to once every too polls. However, when dealing with many
spec events, we can wait very long and skipping epoll_wait() every second
time increases latency. For this reason, we try to detect if we are beyond
a reasonable limit and stop doing so at this stage.
2008-05-25 10:39:02 +02:00
2008-04-19 21:25:12 +02:00
2006-06-15 21:48:13 +02:00
2008-04-19 21:25:12 +02:00
2008-04-19 21:25:12 +02:00

                           -------------------
                             H A - P r o x y
                             How to build it
                           -------------------
                              version 1.3.15
                              willy tarreau
                                2008/05/25


To build haproxy, you will need :
  - GNU make. Neither Solaris nor OpenBSD's make work with this makefile.
    However, specific Makefiles for BSD and OSX are provided.
  - GCC between 2.91 and 4.3. Others may work, but not tested.
  - GNU ld

Also, you might want to build with libpcre support, which will provide a very
efficient regex implementation and will also fix some badness on Solaris's one.

To build haproxy, you have to choose your target OS amongst the following ones
and assign it to the TARGET variable :

  - linux22     for Linux 2.2
  - linux24     for Linux 2.4 and above (default)
  - linux24e    for Linux 2.4 with support for a working epoll (> 0.21)
  - linux24eold for Linux 2.4 with support for a broken  epoll (<= 0.21)
  - linux26     for Linux 2.6 and above
  - solaris     for Solaris 8 or 10 (others untested)
  - freebsd     for FreeBSD 5 to 6.2 (others untested)
  - openbsd     for OpenBSD 3.1 to 3.7 (others untested)
  - generic     for any other OS.
  - custom      to manually adjust every setting

You may also choose your CPU to benefit from some optimizations. This is
particularly important on UltraSparc machines. For this, you can assign
one of the following choices to the CPU variable :

  - i686 for intel PentiumPro, Pentium 2 and above, AMD Athlon
  - i586 for intel Pentium, AMD K6, VIA C3.
  - ultrasparc : Sun UltraSparc I/II/III/IV processor
  - generic : any other processor or no specific optimization. (default)

Alternatively, you may just set the CPU_CFLAGS value to the optimal GCC options
for your platform.

If your system supports PCRE (Perl Compatible Regular Expressions), then you
really should build with libpcre which is between 2 and 10 times faster than
other libc implementations. Regex are used for header processing (deletion,
rewriting, allow, deny). The only inconvenient of libpcre is that it is not
yet widely spread, so if you build for other systems, you might get into
trouble if they don't have the dynamic library. In this situation, you should
statically link libpcre into haproxy so that it will not be necessary to
install it on target systems. Available build options for PCRE are :

  - USE_PCRE=1 to use libpcre, in whatever form is available on your system
    (shared or static)

  - USE_STATIC_PCRE=1 to use a static version of libpcre even if the dynamic
    one is available. This will enhance portability.

  - with no option, use your OS libc's standard regex implemntation (default).
    Warning! group references on Solaris seem broken. Use static-pcre whenever
    possible.

By default, the DEBUG variable is set to '-g' to enable debug symbols. It is
not wise to disable it on uncommon systems, because it's often the only way to
get a complete core when you need one. Otherwise, you can set DEBUG to '-s' to
strip the binary.

For example, I use this to build for Solaris 8 :

    $ make TARGET=solaris CPU=ultrasparc USE_STATIC_PCRE=1

And I build it this way on OpenBSD or FreeBSD :

    $ make -f Makefile.bsd REGEX=pcre DEBUG= COPTS.generic="-Os -fomit-frame-pointer -mgnu"

If you need to pass other defines, includes, libraries, etc... then please
check the Makefile to see which ones will be available in your case, and
use the USE_* variables in the GNU Makefile, or ADDINC, ADDLIB, and DEFINE
variables in the BSD makefiles.

-- end
Description
No description provided
Readme 50 MiB
Languages
Shell 100%