dispatchmode.yo (3679B)
1 conf(dispatchmode - How are back ends selected) 2 (The dispatch mode controls how crossroads selects a back end from 3 a list of active back ends. The below text shows the bare 4 syntax. See section ref(howselected) for a textual explanation. 5 6 The settings can be: 7 8 itemization( 9 it() tt(dispatchmode roundrobin): Simply the 'next in line' is 10 chosen. E.g, when 3 back ends are active, then the usage 11 series is 1, 2, 3, 1, 2, 3, and so on. 12 13 Roundrobin dispatching is the default method, when no 14 tt(dispatchmode) statement occurs. 15 16 it() tt(dispatchmode random): Random selection. Probably only 17 for stress testing, though when used with weights (see below) 18 it is a good distributor of new connections too. 19 20 it() tt(dispatchmode bysize [ over) em(connections) tt(]): 21 The next back end is the one 22 that has transferred the least number of bytes. This 23 selection mechanism assumes that the more bytes, the heavier 24 the load. 25 26 The modifier tt(over) em(connections) is optional. (The square 27 brackets shown above are not part of the statement but 28 indicate optionality.) When given, 29 the load is computed as an average of the last stated number of 30 connections. When this modifier is absent, then the load is 31 computed over all connections since startup. 32 33 it() tt(dispatchmode byduration [ over) em(connections) tt(]): 34 The next back end is the one 35 that served connections for the shortest time. This mechanism 36 assumes that the longer the connection, the heavier the load. 37 38 it() tt(dispatchmode byconnections): The next back end is the one 39 with the least active connections. This mechanism assumes that 40 each connection to a back end represents load. It is usable 41 for e.g. database connections. 42 43 it() tt(dispatchmode byorder): The first back end is selected 44 every time, unless it's unavailable. In that case the second 45 is taken, and so on. 46 47 it() tt(dispatchmode externalhandler) em(program arguments): 48 This is a special mode, where an external program is delegated 49 the responsibility to say which back end should be used 50 next. In this case, Crossroads will call the external program, 51 and this will of course be slower than one of the 'built-in' 52 dispatch modes. However, this is the ultimate escape when 53 custom-made dispatch modes are needed. 54 55 The dispatch mode that uses an tt(externalhandler) is 56 discussed separately in section ref(externalhandler).) 57 58 The selection algorithm is only used when clients are serviced that 59 aren't part of a sticky HTTP session. This is the case during: 60 61 itemization( 62 it() all client requests of a service type tt(any); 63 it() new sessions of a service type tt(http).) 64 65 When type tt(http) is in effect and a session is underway, then the 66 previously used back end is always selected -- regardless of 67 dispatching mode. 68 69 Your 'right' dispatch mode will depend on the type of service. Given 70 the fact that crossroads doesn't know (and doesn't care) how to 71 estimate load from a network traffic stream, you have to choose an 72 appropriate dispatch mode to optimize load balancing. In most cases, 73 tt(roundrobin) or tt(byconnections) will do the job just fine.) 74 (tt(dispatchmode) em(mode) (see above for the modes), optionally 75 followed by tt(over) em(number), or when the em(mode) is 76 tt(externalhandler), followed by em(program).) 77 (tt(roundrobin)) 78