Expressions Performance
Since Iotellect is heavily based on expressions, estimation of their performance impact is crucial for planning the performance of the whole Iotellect installation.
CPU Load Impact
Some overall notes on expression performance:
1. If an expression refers to variables or functions or contexts located on the local server, its evaluation time will depend only on the time required for the local server to complete the operation. It can differ thousand times depending on the nature of the variable getter algorithm and function implementation code. Reading a local context variable or calling a local context function may also cause a significant CPU load on the local server.
2. Once an expression refers to variables or functions of remote contexts (e.g. contexts on remote servers), its evaluation takes significant time and can cause the remote server's CPU load. The time required to evaluate the expression that includes a remote context reference is a sum of:
The network round-trip time required to send a command (e.g. get/set variable or call function command) to the remote server and get a reply (generally equal to the result of
pingcommand)The time required for the remote server to process the command
3. In all other cases, expression processing is generally very fast and doesn't have a noticeable CPU load impact. Millions of evaluations per second can be easily handled by any server.
The following table helps to estimate the impact of different expression elements:
Element | Performance |
Basic operations (arithmetic, comparison, logical, conditional, etc.) | Very high. Performance (CPU load) impact can be noticed if an expression is calculated millions of times per second. |
Default table references (e.g. | Very high, millions of operations per second won't cause performance degradation. |
Context references (e.g. | Very high to low, depending on the context location (local or remote) and nature of referred context variable/function. Resolution performance of server-side variable/function references depends on:
See variables performance and functions performance for more information. |
Widget component references (e.g. | High, tens of thousands of operations per second won't cause performance degradation. |
Mathematical functions | Very high, millions of operations per second won't cause performance degradation. |
String processing functions | Very high to high. Minor performance impact is only noticeable when performing operations on very long strings (millions of characters). |
Date/time processing functions | Very high, millions of operations per second won't cause performance degradation. |
Color processing functions | Very high, millions of operations per second won't cause performance degradation. |
Data Table processing functions | Very high to medium, only operations on very large tables (thousands of records) can generally cause noticeable CPU load impact. |
Type conversion functions | Very high, millions of operations per second won't cause performance degradation. |
Context related functions | Very high to low, depending on the context location (local or remote) and nature of referred context variable/function. See variables performance and functions performance for more information. |
Memory Usage Impact
Expressions don't cause constant memory usage. However, evaluation of an expression can cause significant spot memory load if it refers to some context variables or functions those underlying "implementation" code load or generates a lot of temporary data (e.g. load a long list of historical events from a server database or execute a query over ten thousand devices).
Expressions in Distributed Environment
Performance of expression evaluation in a distributed environment can greatly depend on the structure of expressions, so system architects should take care of possible performance degradations. Let's analyze an example expression that is used as a part of widget binding:
addColumns({users.admin.devices.userProvider:userTable}, "<attachedValue><S>", "callFunction('users.admin.devices.userProvider', 'getUserInformation', {columnOfUserTable}")
This expression is normally evaluated on the network host running Iotellect Client or other Iotellect Server user interface. The number of network requests required to evaluate the expression will be 1 + Number_of_records_in_userTable since a separate remote network request will be required for each call of getUserInformation() function. Thus, if network latency (ping time) is 1 second and there are 1000 records in userTable, evaluation of the expression will take approximately 1000 seconds, what's likely unacceptable.
To overcome this issue, it's necessary to "transfer" the expression evaluation point to another side of the connection, i.e. to the side of Iotellect Server. This can be implemented in many ways. For example, a separate User Provider model can be created on the server, with a getExtendedUserTable() function of Expression type. The above expression should be used in this function's parameters, and the widget binding expression itself will just refer this function, e.g. by looking as follows: {users.admin.models.userProvider:getExtendedUserTable()}. In this case, server-side model will perform the evaluation eliminating per-record network calls, and the binding expression will just make a single remote call receiving a pre-built table from the server. Expression evaluation time will decrease to approximately one second, i.e. 1000 times.
Was this page helpful?