The client does choose randomly among the boxes, but they may be busy.
Think SMTP & MX records with multiple primary and secondary servers. The client connects to one of the primary servers. All is good if it can be processed quickly. If not, I want the connection to be rejected so the client tries another primary box. If none of the primaries can take it, then it goes to the secondaries. It should be handled by the primaries if possible, but it should not queue for them: it is more important that it is handled by something quickly, whether primary or secondary.
| [reply] |
Don't know the original poster's exact situation, but for example if you have a relatively small load of long-running transactions, random isn't good enough; if you happen to hit a busy system you really want to at least consider trying another system. (A real load-balancer is the brute force solution of course; one that understands the present load and can accurately predict the future load. But that's often beyond the budget of this kind of setup; and the commercial ones are optimized for large numbers of small transactions rather than the reverse.)
| [reply] |
