In most Mikon installations, more than 50% of all the values are calculated. In this article, written by Mikon Expert Alf Sandsør, you will learn how to load balance and optimise calculations.

There is usually a combination of manually entered values and calculated results on data entry screens. Regardless of their input values, all calculations are performed on the server side. Your input values are passed to the server(s), recognising this as part of an equation. The calculation will be activated, the result stored in the database and optionally displayed on your screen. All data from all sources, both manual and online data, will pass through the same channels. All this will be done on a first-come, first-served basis with a single calculator running.

Suppose you experience that the time to get the result is long. In that case, it is not necessarily due to the system being slow. Still, the calculation might have fallen behind in a long queue of other activities.

To avoid a situation where you expect a quick result but are slowed down by other calculations, you may establish multiple calculators in parallel and assign calculated signals to a specific calculator. The "Calculation Group" is decided when you set up the equation. The default group is 1.

From a computer/CPU point of view, all the calculators run with the same priority managed by the OS. To prioritise a signal calculation, you simply assign it to a calculator with a few other signals.

Setting up Multiple Calculators

A standard Mikon installation comes with one calculator installed and running, but the system and database schema is initially prepared for 3. To set up more, go to the "binay" folder for the Mikon Application Server and write

This example is for Calculator # 3. The number could be 1 to 9, but for # > 3, some extra configuration effort is required.

To ensure the system recognises that you will utilise more than one calculator, make sure the environment variable MI_MAX_CALCULATORS is set to the total number of calculators installed.

Distributing Calculated Signals

The number of signals where you expect a quick return based on manual data entry usually is not very high. Assign them to the same calculator and keep other calculations somewhere else. Then the chance of falling behind in a long line of other activities is small.

Any signal calculation that may end up in a big bulk of calculations should be assigned to their own calculators. These could be calculations that trigger forward, especially time series calculations like AVGT and SMT. One single entry could quickly result in several hundred calculations that could create large queues.

Suppose a single Mikon installation serves several independent systems, like production and emission control. In that case, it may be practical to split the related calculations into separate groups.

Tuning the Calculators

There is a set of environment variables for each calculator that will influence the performance and throughput of calculations.

MI_OCALCn_FREQ

The number of seconds the IISERVER process waits before this process forces a wakeup of the calculator number 'n'. For calculators with high priority signals, this should be set low to avoid a too-long wait before it is started.

MI_OCALCn_TODB

The default is that the calculation results are passed as a standard message to the central process manager. If set to "Y", the result is processed and stored directly in the database. This could provide a faster flow through when calculations pile up.

MI_OCALCn_SENDUNCHANGED

When a calculation is finished, the result is compared with the current value. The default is to pass this result regardless. To save time, you may set this variable to "N". Then, the result is ignored. The advantage is to improve calculation throughput, but it may stop a chain reaction you intended...

MI_OCALCn_REMDUP

Remove duplicates. Some calculation functions (AVGT, SMT) may indirectly create a lot of calculations to be performed for the same combination of signal/product/time. In those specific cases, removing duplicates may be a good performance booster. The default setting is "Y", and we don't see any reasons to change that.

Monitoring the Throughput and Performance

The Mikon architecture is based on messaging between specialised services. There may always be something going on in the background. The latest version of Mikon Classic has a server status indicator in the lower-left corner. When you click on it, you may see how messages are being buffered between services. Under normal circumstances, these buffers are empty (0 in the queue)

The % number is not an accurate measure of anything, but a rough estimate of how busy the services are.

The green "hook" is an indicator that all services are running. If anything is stopped, this will show a warning flag. Click on the warning, and a server status will appear.

Calculator #2 has stopped.

Setting up additional Calculators

The Mikon installation with buffer tables and lookup catalogues for 3 calculators in parallel. If you want to increase this up to the maximum of 9, you need to configure some things at the database level.

When defining an equation, you need to add more options to allow a dropdown of more than options 1 to 3. Do that in "Code Maintenance".

Each calculator uses 2 buffer tables to handle calculation messages. These tables are called calcbufferN and calcbufferN_work, where N is the number of the calculator. Mikon comes with these tables defined for 1 through 3. You need to set up the same pair for each new calculator. Just duplicate the design. For MSSQL it is essential to have the unique identity seed sequence_no defined.