Cold Start Mitigation

Rule Engine Cold Start

The first time a rule application is retrieved and executed, it must be compiled and loaded into memory.  The time it takes for this process to complete is commonly referred to as the cold start.  The cold start time will vary depending primarily on the size of the rule application. After the initial cold start, performance will more adequately represent normal rule engine execution performance.

Mitigating the cold start

A common practice for mitigating the cold start is to force the rules to compile before an end user makes a request for the rule application.  This can be achieved when the application or service is loading.

The following SDK code options will force the rule application to begin compile:

1. The first creation of a InRule.Runtime.Entity
   

   // Create rule application reference and a dummy Entity -- this performs a Metadata compile, but not a Function compile
   var ruleApp = new FileSystemRuleApplicationReference(@"C:\RuleApps\MyRuleApplication.ruleappp");
            

   using (var session = new RuleSession(ruleApp))
   {
       session.CreateEntity("MyEntity");
   }

2. Proactively call the Compile method on the RuleApplicationReference
   

   // Create rule application reference
   var ruleApp = new FileSystemRuleApplicationReference(@"C:\RuleApps\MyRuleApplication.ruleappp");

   // Force a Metadata compile - Function compile will still occur incrementally and on-demand
   ruleAppRef.Compile(CompileSettings.Create(EngineLogOptions.Execution));

Note: When performing a pre-compile as demonstrated above, it is important to set the LogOptions in the CompileSettings to the same value that will be used for execution. If the settings do not match, the first execution will include additional compile time.

There are two main steps to complete a full compilation of a rule application in InRule:

• Metadata Compile - Includes compile of the schema, endpoints, and lists along with rule validation
• Function Compile - Includes compile of rules and state access delegates

By default, the Metadata Compile is always completed the first time a rule application is used by a RuleSession or an explicit call is made to the RuleApplicationReference.Compile method. The Function Compile occurs incrementally and on-demand the first time a particular rule or state accessor is required by a particular rule execution request. In some scenarios, it may be desirable to force the entire Function Compile to occur upfront. To enforce a full upfront compile of a rule application, explicitly pass a CompileSettings instance to the call to RuleApplicationReference.Compile. See the code sample below:

// Create rule application reference
          var ruleApp =
new FileSystemRuleApplicationReference(@"C:\RuleApps\MyRuleApplication.ruleapp");
// Force a full Metadata and Function compile
          ruleApp.Compile(CacheRetention.Default, CompileSettings.Create(EngineLogOptions.None));

There are various techniques for masking cold start mitigation in your rules-enabled application. Following are some of the more commonly used techniques when adding the cold start mitigation code to the 'on load' or 'on start' events of your application:

• Handle the cold start with an asynchronous worker.
• Display a splash screen if dealing with an end-user application.
• Consider disabling buttons or links that engage rule execution until the cold start mitigation is completed.
• For services, consider adding the above mentioned code to an event when the service is started (e.g. APPLICATION_ONSTART, IProcessHostPreloadClient).
• For ASP.NET or WCF applications, implement a startup routine in the Global.asax file.
• Use IIS or Windows Server AppFabric to auto-start services after an Application Pool is recycled

Helping minimize cold start with XmlSerializers

The first time rules are applied in a given AppDomain, the .NET XmlSerializer will attempt to create a temporary XML serializer assembly to perform an XML deserialization of a rule application. Once the temporary serializer assembly is generated and compiled, it is reused for the life of the AppDomain.  The time to generate the serializer assembly can be significant, and can be avoided by deploying a pre-built assembly that InRule provides as part of irSDK. The file named InRule.Repository.XmlSerializers.dll should be copied into the working directory of an application that is consuming InRule to avoid playing the cold start times for regenerating this XML serializer assembly for each new AppDomain.

Configuring IIS to minimize unanticipated cold starts

When InRule is hosted inside of an IIS worker process, it is important to note that IIS has built-in features that will occasionally recycle the worker process. Each time the process is recycled, all of the InRule AppDomain caches are also recycled, and cold start costs due to loading assemblies and compiling rule applications must be repaid. Two settings that affect automatic recycling of IIS application pools are the "Idle Time-out" and "Regular Time Interval". Both of these settings should be set to "zero" to avoid regular recycling of the process that is hosting both the InRule rule engine and the irCatalog. The screen shot below shows an example of configuring these settings using the IIS application pool Advanced Settings screen.

Configuring Rule Compilation to use a Background Thread

When using irCatalog, the rule engine can be configured to check for latest rules and compile rules in a background thread. The background thread compilation can help ease threading contention for applications that use multiple rule applications.

The background thread compilation feature is only available for applications that are integrated with irCatalog. The background thread is enabled by passing a Boolean flag into the constructor of the CatalogRuleApplicationReference. See the code sample below:

// Passing true for the last argument in the constructor will enable background compilation
var ruleApp = new CatalogRuleApplicationReference("MyBackgroundCompiledRuleApp", true);