3.2. How HAProxy works

  1. HAProxy is a single-threaded, event-driven, non-blocking engine combining a very
  2. fast I/O layer with a priority-based scheduler. As it is designed with a data
  3. forwarding goal in mind, its architecture is optimized to move data as fast as
  4. possible with the least possible operations. As such it implements a layered
  5. model offering bypass mechanisms at each level ensuring data doesn't reach
  6. higher levels unless needed. Most of the processing is performed in the kernel,
  7. and HAProxy does its best to help the kernel do the work as fast as possible by
  8. giving some hints or by avoiding certain operation when it guesses they could
  9. be grouped later. As a result, typical figures show 15% of the processing time
  10. spent in HAProxy versus 85% in the kernel in TCP or HTTP close mode, and about
  11. 30% for HAProxy versus 70% for the kernel in HTTP keep-alive mode.
  12.  
  13. A single process can run many proxy instances; configurations as large as
  14. 300000 distinct proxies in a single process were reported to run fine. Thus
  15. there is usually no need to start more than one process for all instances.
  16.  
  17. It is possible to make HAProxy run over multiple processes, but it comes with
  18. a few limitations. In general it doesn't make sense in HTTP close or TCP modes
  19. because the kernel-side doesn't scale very well with some operations such as
  20. connect(). It scales pretty well for HTTP keep-alive mode but the performance
  21. that can be achieved out of a single process generally outperforms common needs
  22. by an order of magnitude. It does however make sense when used as an SSL
  23. offloader, and this feature is well supported in multi-process mode.
  24.  
  25. HAProxy only requires the haproxy executable and a configuration file to run.
  26. For logging it is highly recommended to have a properly configured syslog daemon
  27. and log rotations in place. The configuration files are parsed before starting,
  28. then HAProxy tries to bind all listening sockets, and refuses to start if
  29. anything fails. Past this point it cannot fail anymore. This means that there
  30. are no runtime failures and that if it accepts to start, it will work until it
  31. is stopped.
  32.  
  33. Once HAProxy is started, it does exactly 3 things :
  34.  
  35.   - process incoming connections;
  36.  
  37.   - periodically check the servers' status (known as health checks);
  38.  
  39.   - exchange information with other haproxy nodes.
  40.  
  41. Processing incoming connections is by far the most complex task as it depends
  42. on a lot of configuration possibilities, but it can be summarized as the 9 steps
  43. below :
  44.  
  45.   - accept incoming connections from listening sockets that belong to a
  46.     configuration entity known as a "frontend", which references one or multiple
  47.     listening addresses;
  48.  
  49.   - apply the frontend-specific processing rules to these connections that may
  50.     result in blocking them, modifying some headers, or intercepting them to
  51.     execute some internal applets such as the statistics page or the CLI;
  52.  
  53.   - pass these incoming connections to another configuration entity representing
  54.     a server farm known as a "backend", which contains the list of servers and
  55.     the load balancing strategy for this server farm;
  56.  
  57.   - apply the backend-specific processing rules to these connections;
  58.  
  59.   - decide which server to forward the connection to according to the load
  60.     balancing strategy;
  61.  
  62.   - apply the backend-specific processing rules to the response data;
  63.  
  64.   - apply the frontend-specific processing rules to the response data;
  65.  
  66.   - emit a log to report what happened in fine details;
  67.  
  68.   - in HTTP, loop back to the second step to wait for a new request, otherwise
  69.     close the connection.
  70.  
  71. Frontends and backends are sometimes considered as half-proxies, since they only
  72. look at one side of an end-to-end connection; the frontend only cares about the
  73. clients while the backend only cares about the servers. HAProxy also supports
  74. full proxies which are exactly the union of a frontend and a backend. When HTTP
  75. processing is desired, the configuration will generally be split into frontends
  76. and backends as they open a lot of possibilities since any frontend may pass a
  77. connection to any backend. With TCP-only proxies, using frontends and backends
  78. rarely provides a benefit and the configuration can be more readable with full
  79. proxies.