Distributed calculation is something that which you can select in the context of PL/LPG/CFS , which could can speed up your processing time drastically, but how does it work?The idea is pretty simple, as dramatically.

A non-distributed calculation uses only one NODE node and only one THREAD will be one thread is created, while whereas the distributed one calculation dynamically select selects the number of NODES nodes which has have a configurable numbers number of THREADS threads that are going to be created per NODE node to perform the calculation.

Please look closer on provided Here are some examples of distributed types of calculations (enabled/disabled), as it was created without accessing the pricefx-core code, the idea should be kept as how does it work in real lifecalculation types.

Non-

...

Distributed Calculation

This flow show shows an example of a calculation process for non-distributed calculation.

ExampleSample setup in the UI: Image RemovedImage Added 

Image RemovedImage Added

Distributed Calculation

This flow show shows an example of a calculation process for a distributed calculation.

It was built based on the non-distributed calculation flow chart , but the idea is to show the processes only for the one NODE node (which in fact might have a lot of many more THREADS), but the process is the same on all NODES, the number of NODES threads). The number of nodes for calculation is dynamically createdset, so it is hard to predict how many NODES nodes and how many threads you are going to have in the game and how many THREADS in total.

Example: Image Removed

Image Removedtotal. But the process is the same on all nodes.

Sample setup in the UI: Image Added

Image Added

Example

Based on this flow, imagine let's assume that you will have 6000 items to be calculated , those and they are going to be split for among all of the nodes.

For example, if you have 3 nodes in the game, let's say that that this number will be divided by 3, having said then NODE1 will have 2000 items, NODE2 will have also 2000 items, NODE3 will have 2000the same.

Next The next step is to split those these items for the into batches and jobs to be calculated in (each node and thread will work in parallel), having said that there is going to .

There will be 5 threads per node , and we will end up having: On NODE1 there are 400 items to be calculated (2 batches) per THREAD, thread and the same for the other ones, meaning that the api.global will be shared only between THREAD threads (not NODE) meaning that nodes) and so you cannot pass items between nodes using api.global. Instead, in that case api.getSharedCache()/set.../remove... methods should be used , which then can be accessed between nodes and it's its threads. 

In the pricefx-config.xml file, you can restrict the number of parallel slave threads for a given job by its size. The definition MUST must be sorted from low to high. The key defines the maximum job size for this slave count (="up to" semantics).

<maxSlaveThreadsPerJobMap>

...

  <upto_5000>1</upto_5000>

...

  <upto_20000>2</upto_20000>

...

  <upto_50000>3</upto_50000>

...

  <upto_10000000>4</upto_10000000>

...

</maxSlaveThreadsPerJobMap>

Q&A

Q: Is there any

...

minimum limit

...

determining if the job

...

creates batches or not?

...

A: Yes but it may vary in different environments, so please verify with Support.

• In shared production, if there are more than 2000 items, then the calculation will create batches and then calculate them, if . If the limit is not metreached, batches will always return null and calculation will only be only performed in the row calculation level.

• This limit (5000 by default) is set in the

  price fx

  Pricefx configuration file (server/config/pricefx-config.xml) as follows:

         

  Code Block
  <!--  Configuration values applicable if the node is a calculation slave -->

  <calculationSlave>

  <!-- Minimum number of items to process to allow/use distributed mode -->

  <itemThreshold>5000</itemThreshold>

  </calculationSlave>

   Is

  
  

Q: Is it worth using

...

in all cases?

...

A: Generally yes. Moreover, if you are worried about performance, this is the first point

...

you should

...

check.

Q: I

...

cannot use api.addOrUpdate() method in the distributed calculation, is there any workaround

...

?

A: Yes, there is

...

api.boundCall() which can be called including batches, but it is not recommended to use. However,

...

if you do it

...

safely, it will make sense (addOrUpdate only specific sort of keys, not the same)

...

.