← Back to branch summary

~ubuntu-branches/ubuntu/intrepid/haproxy/intrepid

« back to all changes in this revision

Viewing changes to doc/haproxy-en.txt

  • Committer: Bazaar Package Importer
  • Author(s): Arnaud Cornet
  • Date: 2008-03-09 21:30:29 UTC
  • mfrom: (1.1.1 upstream)
  • Revision ID: james.westby@ubuntu.com-20080309213029-8oupnrc607mg5uqw
Tags: 1.3.14.3-1
* New Upstream Version
* Add status argument support to init-script to conform to LSB.
* Cleanup pidfile after stop in init script. Init script return code fixups.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/haproxy-en.txt
322
322
 
323
323
    # to reload a new configuration with minimal service impact and without
324
324
    # breaking existing sessions :
325
 
    # haproxy -f haproxy.cfg -p $(</var/run/haproxy-private.pid) -st $(</var/run/haproxy-private.pid)
 
325
    # haproxy -f haproxy.cfg -p /var/run/haproxy-private.pid -sf $(</var/run/haproxy-private.pid)
326
326
 
327
327
1.7) Polling mechanisms
328
328
-----------------------
651
651
    after 3 seconds, a time-out equal to, or lower than 3 seconds cannot
652
652
    compensate for a packet loss. A 4 seconds time-out seems a reasonable
653
653
    minimum which will considerably reduce connection failures.
654
 
 
 
654
  - starting with version 1.3.14, it is possible to specify timeouts in
 
655
    arbitrary time units among { us, ms, s, m, h, d }. For this, the integer
 
656
    value just has to be suffixed with the unit.
655
657
 
656
658
2.6) Attempts to reconnect
657
659
--------------------------
839
841
                sessions 
840
842
- <holdtime> after this inactivaty time, in ms, the cookie will be deleted 
841
843
             from the sessionstore
 
844
- starting with version 1.3.14, it is possible to specify timeouts in
 
845
  arbitrary time units among { us, ms, s, m, h, d }. For this, the integer
 
846
  value just has to be prefixed with the unit.
842
847
 
843
848
The appsession is only per 'listen' section possible.
844
849
 
852
857
       cookie ServerID insert nocache indirect
853
858
       # Will memorize 52 bytes of the cookie 'JSESSIONID' and keep them
854
859
       # for 3 hours. It will match it in the cookie and the URL field.
855
 
       appsession JSESSIONID len 52 timeout 10800000
 
860
       appsession JSESSIONID len 52 timeout 3h
856
861
       server first1 10.3.9.2:10805 check inter 3000 cookie first
857
862
       server secon1 10.3.9.3:10805 check inter 3000 cookie secon
858
863
       server first1 10.3.9.4:10805 check inter 3000 cookie first
986
991
        server squid1 192.168.1.1
987
992
        server squid2 192.168.1.2
988
993
 
 
994
Version 1.3.14 introduced the "balance url_param" method. It consists in
 
995
relying on a parameter passed in the URL to perform a hash. This is mostly
 
996
useful for applications which do not have strict persistence requirements,
 
997
but for which it still provides a performance boost due to local caching.
 
998
Some of these applications may not be able to use a cookie for whatever reason,
 
999
but may be able to look for a parameter passed in the URL. If the parameter is
 
1000
missing from the URL, then the 'round robin' method applies.
 
1001
 
 
1002
Example :
 
1003
---------
 
1004
 
 
1005
# Hash the "basket_id" argument from the URL to determine the server
 
1006
 
 
1007
    listen http_proxy
 
1008
        bind :3128
 
1009
        mode http
 
1010
        balance url_param basket_id
 
1011
        server ebiz1 192.168.1.1
 
1012
        server ebiz2 192.168.1.2
 
1013
 
989
1014
 
990
1015
3.1) Server monitoring
991
1016
----------------------
1364
1389
will receive only 10 simultaneous sessions when the proxy will be under 1000
1365
1390
sessions.
1366
1391
 
 
1392
It is possible to limit server queue length in order to rebalance excess
 
1393
sessions between less busy application servers IF session affinity isn't
 
1394
hard functional requirement (for example it just gives huge performance boost
 
1395
by keeping server-local caches hot and compact). 'maxqueue' option sets a
 
1396
queue limit on a server, as in example below:
 
1397
 
 
1398
... (just the same as in example above)
 
1399
        server pentium3-800 192.168.1.1:80 cookie s1 weight  8 minconn 10 maxconn 100 check maxqueue 50
 
1400
        server opteron-2.0G 192.168.1.2:80 cookie s2 weight 20 minconn 30 maxconn 300 check maxqueue 200
 
1401
        server opteron-2.4G 192.168.1.3:80 cookie s3 weight 24 minconn 30 maxconn 300 check
 
1402
 
 
1403
Absence of 'maxqueue' option means unlimited queue. When queue gets filled
 
1404
up to 'maxqueue' client session is moved from server-local queue to a global
 
1405
one.
 
1406
 
1367
1407
Notes :
1368
1408
-------
1369
1409
  - The requests will not stay indefinitely in the queue, they follow the
1525
1565
        option clitcpka # enables keep-alive only on client side
1526
1566
        option srvtcpka # enables keep-alive only on server side
1527
1567
 
 
1568
4.1.4) TCP lingering
 
1569
--------------------
 
1570
It is possible to disable the system's lingering of data unacked by the client
 
1571
at the end of a session. This is sometimes required when haproxy is used as a
 
1572
front-end with lots of unreliable clients, and you observe thousands of sockets
 
1573
in the FIN_WAIT state on the machine. This may be used in a frontend to affect
 
1574
the client-side connection, as well as in a backend for the server-side
 
1575
connection :
 
1576
 
 
1577
        option nolinger # disables data lingering
 
1578
 
1528
1579
 
1529
1580
4.2) Event logging
1530
1581
------------------