User Tools

Site Tools


performance_optimization

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Next revisionBoth sides next revision
performance_optimization [2021/01/16 09:54] – [General rules for optimizing your projects] emozolyakperformance_optimization [2021/07/21 08:33] – [General rules for optimizing your projects] emozolyak
Line 112: Line 112:
 ===== General rules for optimizing your projects ===== ===== General rules for optimizing your projects =====
  
-At the time When the webhmi was , +At the time when the WebHMI was inventedit supposed to be used in relatively small projects. But with time, more and more customers installed them for quite big projects. Also, the functionality of the front-end part has been increasing constantly, so that when you're going to use it in the project with thousands of tags with the device fw above 3.5, you should remember about finite platform resources you have.  
 +Below there are several considerations you may follow to keep you project fast and responsive: 
 + 
 + 
 +=== Keep the number of registers in the project below 2-3K === 
 +Each register in the project has a lot of configuration data associsted with it, the bigger the register tree, the more load will lay upon the system. That may slow down the response when you work with the register tree. Organize your register tree in categorites.  
 + 
 +=== Vizialization ===
  
   -Use screens wherever is possible for visualisation, and use dashboards as a part of screens for graphic part, which can not be done with the screens.   -Use screens wherever is possible for visualisation, and use dashboards as a part of screens for graphic part, which can not be done with the screens.
-  -Avoid using bulky DASHBOARDS (too rich in elements, having heavy-weight pictures etc. ), "normal" dashboard is about tens of KB, not MB! +  -Avoid using bulky dashboards (too rich in elements, having heavy-weight pictures etc. ), "normal" dashboard is about tens of KB, not MB! (you can check dashboard size exporting it into en external file)
-  -Avoid using many scripts (like dashboards scripts or upon change value scripts). The better way is using a few big scripts or scripts with libraries  instead of a lot of small scripts (each script takes some os environment) +
-  -Run scripts upon changing value, minimize the number of scripts, running in each scan +
-  -Minimize "WriteReg" Lua instructions in each scan.  It is better to use wrapping function UpdateReg(), which write to register only if value has changed. +
-  -Group register to read on external device and use group reading. +
-  -Set appropriate timeout and tries in external connections  E.g. if the device has common timeout of 30 ms, set it about 40 ms. If the deivce gets lost, with bigger timeout of 100 ms, if its possible. Use auto-drop&try for not available connections. +
-  -Organize and set different reading periods for variables. +
-  -Use event communication.+
   -Set appropriate screen refresh time.   -Set appropriate screen refresh time.
-  -Keep the number of open tabs minimal for the current sessions. If you need multiple tabsuse auto-close session checkbox to prevent unattended access. +  -use templates for dashboardsalerts and others 
-  -During development, keep parameter Load Average below 1 + 
-  -Avoid making simultaneous changes at once, like turning OFF-ON many regs, connection, scripts etc. Use save & apply feature of the latest fw(apply all changes at once, instead of creating queue for changes..) +=== Scripting === 
-  -Minimize logging many registers to DBset appropriate log speed for them+  -Avoid using many scripts. The better way is using a few big scripts or scripts with libraries  instead of a lot of small scripts (each script takes some os environment)Best practice is when script list fits into one page, and each scripts fits into editor windows w/o scrolling it down.  
-  -Keep the number of registers in the project below 2-3K+  -Run scripts upon changing valueminimize the number of scripts, running in each scan
 +  -Minimize "WriteReg" Lua instructions in each scan. Becuase WriteRegs are placed into the writing queue, a heedless loop, or using WriteReg in the 100 scripts to update some logic results in creating write queue for 100 tags in each scan (remember each register actually mean a big data sctucture of its properties). It is better to use wrapping function UpdReg() like this: 
  
 <code lua> <code lua>
Line 134: Line 135:
     local cur_value = R(reg)     local cur_value = R(reg)
          
-    if (not cur_value) or (cur_value == new_value) then  +    if (not cur_value) or (not new_value) or (cur_value == new_value) then  
-        return +        return false 
     else     else
-        W(reg, new_value)+        WriteReg(reg, new_value)
     end      end 
 end  end 
 </code> </code>
 +
 +=== Connections ===
 +  -Use group registers feature 
 +  -Set appropriate timeout and tries in external connections  E.g. if the device has common timeout of 30 ms, set it about 40 ms. If the device gets lost, with bigger timeout set to 100 ms, each scan it will take extra 60 ms on read tries. Use "skip", "auto-drop & probe" options for not stable connections.
 +  -Organize and set different reading intervals for variables. E.g. for device settings (like PID coeficitens, tolerances and other setup data) you set "Read-On-Demand" property, for slow parameters, like temperature you set 1 minute and so on. 
 +  -For mulitple external devices, you can use "sliding" [[performance_of_data_exchange| connection window trick]] to temprorarily access a device.
 +
 +=== Project editing ===
 +
 +  -Keep the number of open tabs in browser minimal for the current session. If you need multiple tabs, use auto-close session checkbox to prevent unattended access.
 +  -Avoid making multiple changes in series, like turning OFF-ON many regs, connection, scripts etc. Use save & apply feature of the latest fw. (apply all changes at once, instead of creating a queue for changes)
 +
 +=== Track Load Average parameter ===
 +There is a metric register in the internal register showing mean number of the processes in the queue relative to the running process. There are 1, 5, 15 minutes mean paratemer. In a steady state, you 15 minutes metric should be below 1. 
 +
 +=== Optimize log===
 +  -Minimize logging many registers to DB, set appropriate log speed for them. When setting 'use data from log' for the graphs, make sure you limit the log amount with the setting.
 +
 +
 +
  
  
  
  
performance_optimization.txt · Last modified: 2023/05/03 08:54 by emozolyak

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki