Dashboard > GridGain User Guide > Table Of Contents > Developers Guide > Load Balancing SPI > GridAdaptiveLoadBalancingSpi > Information > Page Comparison
GridGain User Guide
GridAdaptiveLoadBalancingSpi
Version 18 by morpheus
on Feb 12, 2008 03:27.

<< Changes from 17 to 18
compared with
Current by morpheus
on Feb 17, 2008 22:41.
(show comment)
 
Key
These lines were removed. This word was removed.
These lines were added. This word was added.

View page history


There are 1 changes. View first change.

 * [#Package]
 * [#Description]
 ** [#Adaptive Node Probes]
 *** [#Grid Adaptive CPU Load Probe]
 *** [#Grid Adaptive Benchmark Load Probe]
 *** [#Grid Adaptive Processing Time Load Probe]
 *** [#Grid Adaptive Job Count Load Probe]
 * [#Configuration]
 * [#Examples]
  
 {javadocnote}
  
 h2. Package
 *org.gridgain.grid.spi.loadbalancing.adaptive* ^[Javadoc|org/gridgain/grid/spi/loadbalancing/jobs/package-summary.html@javadoc]^
  
 *Available starting with GridGain !http://www.gridgain.com/images/small_20.gif!*
 h2. Description
 {{GridAdaptiveLoadBalancingSpi}} {javadoc:spi/loadbalancing/adaptive/GridAdaptiveLoadBalancingSpi.html} adapts to overall node performance. It proportionally distributes more jobs to more performant nodes based on a pluggable and dynamic node load probing.
  
 h3. 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:spi/loadbalancing/adaptive/GridAdaptiveLoadProbe.html} interface and user is free to provide custom implementations. By default {{GridAdaptiveCpuLoadProbe}} {javadoc:spi/loadbalancing/adaptive/GridAdaptiveCpuLoadProbe.html} 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:spi/loadbalancing/adaptive/GridAdaptiveLoadProbe.html#getLoad(org.gridgain.grid.GridNode,%20int)} 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:GridConfiguration.html#getMetricsExpireTime()} and {{GridConfiguration.getMetricsHistorySize()} {javadoc:GridConfiguration.html#getMetricsHistorySize()} 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:
 {code}
 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();
  }
 }
 {code}
 h3. 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]
  
 h3. Grid Adaptive CPU Load Probe
 {{GridAdaptiveCpuLoadProbe}} {javadoc:spi/loadbalancing/adaptive/GridAdaptiveCpuLoadProbe.html} implementation of node load probing based on CPU load.
  
 The following configuration parameters can be used to configure {{GridAdaptiveCpuLoadProbe}} {javadoc:spi/loadbalancing/adaptive/GridAdaptiveCpuLoadProbe.html}:
 || Setter Method || Description || Optional || Default ||
 | {{setUseAverage(boolean)}} {javadoc:spi/loadbalancing/adaptive/GridAdaptiveCpuLoadProbe.html#setUseAverage(boolean)} | Indicates whether implementation should either use average CPU load values or current. | Yes | Default value is {{true}} |
 |{{setUseProcessors(boolean)}} {javadoc:spi/loadbalancing/adaptive/GridAdaptiveCpuLoadProbe.html#setUseProcessors(boolean)} | 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:spi/loadbalancing/adaptive/GridAdaptiveCpuLoadProbe.html#setProcessorCoefficient(double)} | 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:
 {code:xml}
 <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>
 {code}
 This probe implementation is used by default by {{GridAdaptiveLoadBalancingSpi}} SPI.
  
 h3. Grid Adaptive Benchmark Load Probe
 {{GridAdaptiveBenchmarkLoadProbe}} {javadoc:spi/loadbalancing/adaptive/GridAdaptiveBenchmarkLoadProbe.html} uses {{GridLocalNodeBenchmark}} {javadoc:benchmarks/GridLocalNodeBenchmark.html} for specifying load for every node. In order to use this probe, use should configure every grid node to start with {{GridLocalNodeBenchmark}} {javadoc:benchmarks/GridLocalNodeBenchmark.html} as attribute (see {{GridConfiguration.getUserAttributes()}} {javadoc:GridConfiguration.html#getUserAttributes()} for more information).
  
 You can initialize local node benchmarks by adding/uncommenting the following section in GridGain Spring XML file:
 {code:xml}
 <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>
 {code}
 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.
  
 h3. Grid Adaptive Processing Time Load Probe
 {{GridAdaptiveProcessingTimeLoadProbe}} {javadoc:spi/loadbalancing/adaptive/GridAdaptiveProcessingTimeLoadProbe.html} provides implementation of node load probing based on total job processing time.
  
 Based on {{GridAdaptiveProcessingTimeLoadProbe.setUseAverage(boolean)} {javadoc:spi/loadbalancing/adaptive/GridAdaptiveProcessingTimeLoadProbe.html#setUseAverage(boolean)}
 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:
 {code:xml}
 <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>
 {code}
  
 h3. Grid Adaptive Job Count Load Probe
 {{GridAdaptiveJobCountLoadProbe}} {javadoc:spi/loadbalancing/adaptive/GridAdaptiveJobCountLoadProbe.html} provides implementation of node load probing based on active and waiting job count.
  
 Based on {{GridAdaptiveJobCountLoadProbe.setUseAverage(boolean)} {javadoc:spi/loadbalancing/adaptive/GridAdaptiveJobCountLoadProbe.html#setUseAverage(boolean)} 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:
 {code}
 <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&gt;
  </property>
 {code}
  
 h2. Configuration
 The following configuration parameters can be used to configure {{GridAdaptiveLoadBalancingSpi}} {javadoc:spi/loadbalancing/adaptive/GridAdaptiveLoadBalancingSpi.html}
 || Setter Method || Description || Optional || Default ||
 | {{setLoadProbe(GridAdaptiveLoadProbe)}} {javadoc:spi/loadbalancing/adaptive/GridAdaptiveLoadBalancingSpi.html#setLoadProbe(org.gridgain.grid.spi.loadbalancing.adaptive.GridAdaptiveLoadProbe)} | This configuration parameter supplies a custom algorithm for probing a node's load. | Yes | Default value is {{GridAdaptiveCpuLoadProbe}} {javadoc:spi/loadbalancing/adaptive/GridAdaptiveCpuLoadProbe.html} which takes every node's CPU load and tries to send proportionally more jobs to less loaded nodes. |
  
 h2. Examples
 As any GridGain SPI, {{GridAdaptiveLoadBalancingSpi}} {javadoc:spi/loadbalancing/adaptive/GridAdaptiveLoadBalancingSpi.html} SPI can be configured either directly from code or from Spring configuration file. Here is an example of {{GridAdaptiveLoadBalancingSpi}} configuration from code:
 {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);
 {code}
  
 or from Spring configuration file
  
 {code:xml}
 <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>
 {code}
  
 {spring}
Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.2.10 Build:#528 Nov 29, 2006) - Bug/feature request - Contact Administrators