If you want the appliance to increase the load on a new service automatically at specified intervals until the service can be considered capable of handling its full share of the load, set the new service request rate parameter, the units parameter, and the increment interval. When all the parameters are set to values other than 0, the appliance increments the load on a new service by the value of the new service request rate, at the specified interval, until the service is receiving its full share of the load.
As an example, assume that four services, Service1, Service2, Service3, and Service4, are bound to a load balancing virtual server, vserver1. Further assume that vserver1 receives 100 requests per second, and that it distributes the load evenly across the services (25 requests per second per service). When you add a fifth service, Service5, to the configuration, you might want the appliance to send the new service 4 requests per second for the first 10 seconds, 8 requests per second for the next 10 seconds, and so on, until it is receiving 20 requests per second. For this requirement, the following table shows the values to which you set the three parameters:
Table 3. Parameter Values
| Parameter |
Value |
| Interval in seconds |
10 |
| Increment value |
4 |
| Units for the new service request rate |
Requests per second |
With this configuration, the new service begins receiving as many requests as the existing services 50 seconds after it is added or its state has changed from DOWN to UP. During each interval in this period, the appliance distributes to the existing servers the excess of requests that would have been sent to the new service in the absence of stepwise increments. For example, in the absence of stepwise increments, each service, including Service5, would have received 20 requests each per second. With stepwise increments, during the first 10 seconds, when Service5 receives only 4 requests per second, the appliance distributes the excess of 16 requests per second to the existing services, resulting in the distribution pattern shown in the following table and figure over the 50-second period. After the 50-second period, Service5 is no longer considered a new service, and it receives its normal share of traffic.
Table 4. Load Distribution Pattern on All Services for the 50-second Period Immediately after Service5 is Added
|
0 sec |
10 sec |
20 sec |
30 sec |
40 sec |
50 sec |
| Req/sec forService1 |
25 |
24 |
23 |
22 |
21 |
20 |
| Req/sec forService2 |
25 |
24 |
23 |
22 |
21 |
20 |
| Req/sec forService3 |
25 |
24 |
23 |
22 |
21 |
20 |
| Req/sec forService4 |
25 |
24 |
23 |
22 |
21 |
20 |
| Req/sec forService5 |
0 |
4 |
8 |
12 |
16 |
20 |
| Total req/sec (load on the virtual server) |
100 |
100 |
100 |
100 |
100 |
100 |
Figure 1. A Graph of the Load Distribution Pattern on All Services for the 50-second Period Immediately after Service5 is Added
An alternative requirement might be for the appliance to send Service5 25% of the load on the existing services in the first 5 seconds, 50% in the next 5 seconds, and so on, until it is receiving 20 requests per second. For this requirement, the following table shows the values to which you set the three parameters.
Table 5. Parameter Values
| Parameter |
Value |
| Interval in seconds |
5 |
| Increment value |
25 |
| Units for the new service request rate |
Percent |
With this configuration, the service begins receiving as many requests as the existing services 20 seconds after it is added or its state has changed from DOWN to UP. The traffic distribution during the ramp-up period for the new service is identical to the one described earlier, where the unit for the step increments was “requests per second.”