The InRule Runtime can cache the results of data queries to reduce latency of querying external data sources that can change infrequently.
The following InRule Queries may be cached:
- Lookup() function
- TableLookup() function
- QueryToList() function
- IsInValueList() function
- ValueListLookup() function
- SQL query functions
- Execute SQL Query action
- Execute REST Service action
Query cache results are cached for any RuleSession in the current AppDomain. Queries that are identical in their parameters across different RuleSessions and source Rule Applications will use the same cached results.
The following query parameters are taken into account when comparing identity:
- Data source, e.g. database connection string, REST service URL
- Query text
- Parameter values
- Cache timeout
Data Elements
How the query results are cached depends on the type of Data Element used in the query, and on any cache settings that may have been configured. The following illustrates the default cache timeout values for different Data Elements; most of them are configurable.
Lookup and TableLookup functions
Target |
Timeout |
Configurable |
Inline Table |
300 seconds |
no |
Linked Table |
300 seconds |
yes |
IsInValueList and ValueListLookup functions
Target |
Timeout |
Configurable |
Query ValueList: Inline Table |
300 seconds |
no |
Query ValueList: Linked Table |
300 seconds |
yes |
Query ValueList: SQL Query |
0 seconds |
yes |
SQL Query function, Execute SQL Query action, and QueryToList() function
Target |
Timeout |
Configurable |
SQL Query |
0 seconds |
yes |
Execute REST Service action
Target |
Timeout |
Configurable |
REST Operation |
0 seconds |
yes |
Any Data Element configured with a zero second cache timeout will not enter the cache, which will result in the target data source being queried each time.
Inline Tables queried by syntax functions will remain in the cache for 300 seconds (five minutes). the underlying data cannot change (unless an override is applied), so they are kept for 300 seconds. The query results are not kept indefinitely in order to allow memory to eventually be reclaimed if the host process does not perform any inline Table queries for an extended period of time.
The cache timeout on an SQL Query will override the setting of the target Inline Table or Linked Table.
Cache Configuration
The underlying cache mechanism uses the System.Runtime.Caching.MemoryCache implementation in the .NET Framework, which may be familiar to users of ASP.NET.
While cached query results may be configured to expire from the cache after a period of time, the cache itself may evict query results when memory pressure is detected, to attempt to avoid an OutOfMemoryException. The default settings cause the cache to poll memory usage every two minutes, and start evicting query results when the cache uses approximately 60% of physical RAM.
If memory pressure is detected, the cache will start evicting query results using a Least-Recently-Used (LRU) algorithm.
To change the default cache memory limit settings, add the following configuration element to the application's .config file:
<appSettings>
<add key="inrule:runtime:dataQueryCache:pollingInterval" value="00:00:10">
<add key="inrule:runtime:dataQueryCache:cacheMemoryLimitMegabytes" value="500">
<add key="inrule:runtime:dataQueryCache:physicalMemoryLimitPercentage" value="20">
</appSettings>
OR
<configuration>
<configSections>
<section name="inrule.runtime"
type="InRule.Runtime.Configuration.RuntimeConfigSectionHandler, InRule.Runtime" />
...
</configSections>
...
<inrule.runtime>
<dataQueryCache
pollingInterval="00:00:10"
cacheMemoryLimitMegabytes="500"
physicalMemoryLimitPercentage="20" />
</inrule.runtime>
</configuration>
The above example changes the polling interval to 10 seconds, sets a cache memory limit of 500MB, and sets a physical memory limit of 20%. If only one limit is used, either set the other limit to zero or omit it altogether.
In practice, memory pressure detection does not trigger until a Generation 2 Garbage Collection occurs.
If the Cache Memory Limit is used, the .NET Framework does not enforce this value as a hard limit; the memory used may significantly exceed the configured valu8e until a Generation 2 Garbage Collection occurs, at which point the cache will be trimmed to the configured value.
Comments
0 comments
Please sign in to leave a comment.