Load-balancing is solely based on the value oft he attribute „quality“ which will be freshly computed every 5 minutes. This value is based with a proportion of 5:1 (note 51789) on the average response time. The average response time though might in some cases not be representative, especially in cases where the share of „normal“ GUI-users is relatively small, compared to RFC- and batch-users (like e.g. early mornings before the GUI-users start showing up). The value „quality“ compares in such a moment a bad average response time, although not representative because lack of GUI users, of one of the instances (lets call it ap1) with the average response time of a second instance (ap2) and continues to send the users to ap2, 99% of which way this goes is random.
SAP knows about this Problem (note 51789). If you do not want to change the proportions in the coding, you can still influence the balancing by defining threshholds in SMLG (attributes behind the logon group). Here’s the algorithm for „quality“
- quality = user-part-quality * user-evaluation (1) + response-time part-quality * response time evaluation (5)
- „part quality“ = rounded: 100 – (100 * actual value of the instance / preset value). In words: how many percent are still missing, until the actual value meets 100% of the predefined threshold? If it’s more, the value is negative.
If you do not define thresholds (attributes in SMLG), the system will react as follows:
- As an assumed calculated threshold the actual maximum value from all instances in the group will be taken (i. e. every response-time adds to a „good“ quality value, as long as the special effect mentioned in the first paragraph still enables at least one that’s worse)
- Part quality = part quality + 1
- If the threshold of the response time is undefined, the user-part-quality will be evaluated 2 times instead of 1 (but not the other way around)
I posted an example of how this calculation looks here.