GridAdaptiveLoadBalancingSpi

Package
Description
- Adaptive Node Probes
Configuration
Examples

Click on ^Javadoc link to open Javadoc documentation.

Package

org.gridgain.grid.spi.loadbalancing.adaptive ^Javadoc

Available starting with GridGain

Description

GridAdaptiveLoadBalancingSpi ^Javadoc adapts to overall node performance. It proportionally distributes more jobs to more performant nodes based on a pluggable and dynamic node load probing.

Adaptive Node Probes

This SPI comes with pluggable algorithm to calculate a node load at any given point of time. The algorithm is defined by pluggable GridAdaptiveLoadProbe ^Javadoc interface and user is free to provide custom implementations. By default GridAdaptiveCpuLoadProbe ^Javadoc implementation is used which distributes jobs to nodes based on average CPU load on every node.

Note that if GridAdaptiveLoadProbe.getLoad(org.gridgain.grid.GridNode, int) ^Javadoc returns a value of 0, then implementation will assume that load value is simply not available and will try to calculate an average of load values for other nodes. If such average cannot be obtained (all node load values are 0), then a value of 1 will be used for all nodes.

When working with node metrics, take into account that all averages are calculated over metrics history size defined by GridConfiguration.getMetricsExpireTime() ^Javadoc and {{GridConfiguration.getMetricsHistorySize()} ^Javadoc grid configuration parameters. Generally the larger these configuration parameter values are, the more precise the metrics are. You should tune these values based on the level of accuracy needed vs. the additional memory that would be required for storing metrics.

You should also keep in mind that metrics for remote nodes are delayed (usually by the heartbeat frequency). So if it is acceptable in your environment, set the heartbeat frequency to be more inline with job execution time. Generally, the more often heartbeats between nodes are exchanged, the more precise the metrics are. However, you should keep in mind that if heartbeats are exchanged too often then it may create unnecessary traffic in the network. Heartbeats (or metrics update frequency) can be configured via underlying Discovery SPI used in your grid.

Here is an example of how probing can be implemented to use number of active and waiting jobs as probing mechanism:

public class FooBarLoadProbe implements GridAdaptiveLoadProbe {
    // Flag indicating whether to use average value or current.
    private int useAvg = true;
    
    public FooBarLoadProbe(boolean useAvg) {
        this.useAvg = useAvg;
    }
    
    // Calculate load based on number of active and waiting jobs.
    public double getLoad(GridNode node, int jobsSentSinceLastUpdate) {
        GridNodeMetrics metrics = node.getMetrics();
      
        if (useAvg == true) {
            double load = metrics.getAverageActiveJobs() + metrics.getAverageWaitingJobs();
          
            if (load > 0) {
                return load;
            }
        }
      
        return metrics.getCurrentActiveJobs() + metrics.getCurrentWaitingJobs();
    }
}

Which Node Probe To Use

There is no correct answer here. Every single node probe will work better or worse in different environments. CPU load probe (default option) is the safest approach to start with as it simply attempts to utilize every CPU on the grid to the maximum. However, you should experiment with other probes by executing load tests in your environment and observing which probe gives you best performance and load balancing.

The following load probes are available with the product:

Grid Adaptive CPU Load Probe
Grid Adaptive Benchmark Load Probe
Grid Adaptive Processing Time Load Probe
Grid Adaptive Job Count Load Probe

Grid Adaptive CPU Load Probe

GridAdaptiveCpuLoadProbe ^Javadoc implementation of node load probing based on CPU load.

The following configuration parameters can be used to configure GridAdaptiveCpuLoadProbe ^Javadoc :

Setter Method	Description	Optional	Default
`setUseAverage(boolean)` ^Javadoc	Indicates whether implementation should either use average CPU load values or current.	Yes	Default value is `true`
`setUseProcessors(boolean)` ^Javadoc	Indicates whether implementation should either take number of processors on the node into account or not. Since CPU load on multi-processor boxes shows medium load of multiple CPU's it usually means that the remaining capacity is proportional to the number of CPU's (or cores) on the node. This configuration parameter indicates whether to divide each node's CPU load by the number of processors on that node.	Yes	Default value is `true`.
`setProcessorCoefficient(double)` ^Javadoc	In some environments every processor may not be adding `100%` of processing power. For example, if you are using multi-core CPU's, then addition of every core would probably result in about `75%` of extra CPU power. To account for that, you should set this parameter parameter to `0.75` .	Yes	Default value is `1`

Below is an example of how CPU load probe would be configured in GridGain Spring configuration file:

<property name="loadBalancingSpi">
    <bean class="org.gridgain.grid.spi.loadbalancing.adaptive.GridAdaptiveLoadBalancingSpi">
        <property name="loadProbe">
            <bean class="org.gridgain.grid.spi.loadbalancing.adaptive.GridAdaptiveCpuLoadProbe">
                <property name="useAverage" value="true"/>
                <property name="useProcessors" value="true"/>
                <property name="processorCoefficient" value="0.9"/>
            </bean>
        </property>
    </bean>
</property>

This probe implementation is used by default by GridAdaptiveLoadBalancingSpi SPI.

Grid Adaptive Benchmark Load Probe

GridAdaptiveBenchmarkLoadProbe ^Javadoc uses GridLocalNodeBenchmark ^Javadoc for specifying load for every node. In order to use this probe, use should configure every grid node to start with GridLocalNodeBenchmark ^Javadoc as attribute (see GridConfiguration.getUserAttributes() ^Javadoc for more information).

You can initialize local node benchmarks by adding/uncommenting the following section in GridGain Spring XML file:

<bean id="grid.cfg" class="org.gridgain.grid.GridConfigurationAdapter" scope="singleton">
    <!--
        Grid local node benchmark is a good example of a complex attribute that
        can be added to the node at startup.

        Note that you will have to use 'grid.node.benchmark' grid node attribute name
        to get the benchmark for the given node.
    -->
    <property name="userAttributes">
        <map>
            <entry key="grid.node.benchmark">
                <bean class="org.gridgain.grid.benchmarks.GridLocalNodeBenchmark" init-method="start"/>
            </entry>
        </map>
    </property>

    <!--
        Load balancing SPI that takes node benchmarks into account. Note that
        you are free to configure which benchmark scores to use. The configuration
        below ignores I/O and trigonometry scores.
    -->
    <property name="loadBalancingSpi">
        <bean class="org.gridgain.grid.spi.loadbalancing.adaptive.GridAdaptiveLoadBalancingSpi">
            <property name="loadProbe">
                <bean class="org.gridgain.grid.spi.loadbalancing.adaptive.GridAdaptiveBenchmarkLoadProbe">
                    <!-- Specify name of benchmark node attribute (the same as above). -->
                    <property name="benchmarkAttributeName" value="grid.node.benchmark"/>

                    <!-- Benchmarks scores to use. -->
                    <property name="useIntegerScore" value="true"/>
                    <property name="useLongScore" value="true"/>
                    <property name="useDoulbeScore" value="true"/>
                    <property name="useIoScore" value="false"/>
                    <property name="useTrigonometryScore" value="false"/>
                </bean>
            </property>
        </bean>
    </property>
</bean>

Please make sure to properly initialize this probe to use exactly the scores you need in your grid. For example, if your jobs don't do any I/O, then you probably should disable I/O score. If you are not doing any trigonometry calculations, then you should disable trigonometry score.

Also, keep in mind that the benchmark probe value are constant and do not change throughout node uptime.

Grid Adaptive Processing Time Load Probe

GridAdaptiveProcessingTimeLoadProbe ^Javadoc provides implementation of node load probing based on total job processing time.

Based on {{GridAdaptiveProcessingTimeLoadProbe.setUseAverage(boolean)} ^Javadoc
configuration parameter, this implementation will either use average job execution time values or current (default is to use averages). The algorithm returns a sum of job wait time and job execution time.

Below is an example of how CPU load probe would be configured in GridGain Spring XML configuration file:

<property name="loadBalancingSpi">
    <bean class="org.gridgain.grid.spi.loadbalancing.adaptive.GridAdaptiveLoadBalancingSpi">
        <property name="loadProbe">
            <bean class="org.gridgain.grid.spi.loadbalancing.adaptive.GridAdaptiveProcessingTimeLoadProbe">
                <property name="useAverage" value="true"/>
            </bean>
        </property>
    </bean>
</property>

Grid Adaptive Job Count Load Probe

GridAdaptiveJobCountLoadProbe ^Javadoc provides implementation of node load probing based on active and waiting job count.

Based on {{GridAdaptiveJobCountLoadProbe.setUseAverage(boolean)} ^Javadoc configuration parameter, this implementation will either use average job count values or current (default is to use averages).

The load of a node is simply calculated by adding active and waiting job counts.

Below is an example of how CPU load probe would be configured in GridGain Spring configuration file:

<property name="loadBalancingSpi>;
    <bean class="org.gridgain.grid.spi.loadbalancing.adaptive.GridAdaptiveLoadBalancingSpi">;
        <property name="loadProbe">
            <bean class="org.gridgain.grid.spi.loadbalancing.adaptive.GridAdaptiveJobCountLoadProbe">
                <property name="useAverage" value="true"/>
            </bean>
        <property>
    </bean>
</property>

Configuration

The following configuration parameters can be used to configure GridAdaptiveLoadBalancingSpi ^Javadoc

Setter Method	Description	Optional	Default
`setLoadProbe(GridAdaptiveLoadProbe)` ^Javadoc	This configuration parameter supplies a custom algorithm for probing a node's load.	Yes	Default value is `GridAdaptiveCpuLoadProbe` ^Javadoc which takes every node's CPU load and tries to send proportionally more jobs to less loaded nodes.

Examples

As any GridGain SPI, GridAdaptiveLoadBalancingSpi ^Javadoc SPI can be configured either directly from code or from Spring configuration file. Here is an example of GridAdaptiveLoadBalancingSpi configuration from code:

GridAdaptiveLoadBalancingSpi spi = new GridAdaptiveLoadBalancingSpi();
  
// Configure probe to use latest job execution time vs. average.
GridAdaptiveProcessingTimeLoadProbe probe = new GridAdaptiveProcessingTimeLoadProbe(false);

spi.setLoadProbe(probe);

GridConfigurationAdapter cfg = new GridConfigurationAdapter();
 
// Override default load balancing SPI.
cfg.setLoadBalancingSpi(spi);
 
// Start grid.
GridFactory.start(cfg);

or from Spring configuration file

<bean id="grid.custom.cfg" class="org.gridgain.grid.GridConfigurationAdapter" singleton="true">
    ...
    <property name="loadBalancingSpi">
        <bean class="org.gridgain.grid.spi.loadbalancing.adaptive.GridAdaptiveLoadBalancingSpi">
            <property name="loadProbe">
                <bean class="org.gridgain.grid.spi.loadbalancing.adaptive.GridAdaptiveProcessingTimeLoadProbe">
                    <constructor-arg value="false"/>
                </bean>
            </property>
        </bean>
    </property>
    ...
</bean>

For more information about using Spring framework for configuration click here.

Page Operations

Browse Space