In-memory Models Management
The memory usage settings are used to manage, how long objects are kept in the memory, which affect both the memory usage and performance. The longer the object storing durations, the more memory is consumed, but on the other hand users perceive better performance as analyses are more likely to be found in the memory already calculated. Memory usage settings can be defined in the web.config file and for each model separately in the model settings.
Property | Description |
---|---|
CacheUsage/ DropUnusedModelsAfter |
Duration after which the unused model, is dropped from the memory. Defined in format HH:mm:ss or d.HH:mm:ss, for example 01:00:00 (one hour), 00:30:00 (30 minutes) or 1.00:00:00 (24 hours). When an analysis is requested for a model, the model's last used time is updated (also filter's last used time is updated). If this setting is not defined, the server level default setting is used. |
CacheUsage/ DropUnusedFiltersAfter |
Duration after which the model's unused filters, are dropped from the memory. Defined in format HH:mm:ss or d.HH:mm:ss, for example 01:00:00 (one hour), 00:30:00 (30 minutes) or 1.00:00:00 (24 hours). When an analysis is requested for a filter , the filter's last used time is updated (also model's last used time is updated). If this setting is not defined, the server level default setting is used. |
Configuration Examples
The following configuration keeps the model in memory for 1 hour and filters for 30 minutes.
{ "CacheUsage": { "DropUnusedModelsAfter": "1:00:00", "DropUnusedFiltersAfter": "00:30:00" } }
The following configuration keeps the model in memory for 15 minutes and filters for 5 minutes.
{ "CacheUsage": { "DropUnusedModelsAfter": "0:15:00", "DropUnusedFiltersAfter": "00:05:00" } }
The following configuration keeps the model in memory for 100 days (practically it's never dropped) and filters for 2 hours.
{ "CacheUsage": { "DropUnusedModelsAfter": "100.00:00:00", "DropUnusedFiltersAfter": "02:00:00" } }
Memory Objects Summary
Data handled by QPR ProcessAnalyzer memory is stored in following types of objects:
Stored Objects | Contents | Unused objects dropped after | Time to reload/calculate | Memory consumption |
---|---|---|---|---|
Models | Models objects contain all data in a QPR ProcessAnalyzer model, such as
|
Primarily defined by a model setting CacheUsage/DropUnusedModelsAfter. If the model setting is not defined, the server level setting in the web.config file is used. If the server setting is not defined either, a default value of 10 hours is used. When the is a memory shortage in the server, models are not dropped from the memory. | Slow
Models are loaded from the database requiring to transfer considerable amount of data, which takes much more time than e.g. calculating filters and analyses. |
High |
Filters | Filters contain all filtered data in QPR ProcessAnalyzer model, which includes similar data and structures as the models. | Primarily defined by a model setting. If the model setting is not defined, the server setting is used. If the server setting is not defined, a default value of 1 hour is used. When the is a memory shortage in the server, filters may be dropped from the memory to free memory. | Fast
Filters are calculated from the model data that already exists in the memory. Practically, filters are subsets of models. |
Medium |
Analysis results | Results of the analysis (in tabular form). | Unused analysis results are kept maximum of 30 minutes in the memory if they are not used. When the is a memory shortage in the server, analysis results may be dropped from the memory to free memory. | Fast
Analysis results are calculated from filters, which already exist in memory. |
Low |
Datatable contents | Contents of datatables. | 1 hour. | ||
Script results | 10 minutes. |
If the QPR ProcessAnalyzer server doesn't have enough memory to store more objects, already stored objects are dropped from the memory starting from the one having the longest time from the last usage. Thus, when there is a short of memory, objects may be dropped earlier than their settings define. Only filters and analysis results are dropped during the memory shortage, i.e. model objects are not dropped prematurely. This is because recalculating filters and analysis results is usually faster than loading models from the database. That's why, when trying to load more models than there is available memory in the server, an out of memory error situation may occur.