A good recommendation is to set the cache depth parameter to a value that ensures all rule applications are cached. This way, the delays caused by having to compile and reload a rule application into the cache are minimized, which is the goal.
Also look for Cold Start Mitigation and Managing the RuleApp Cache in the irSDK/InRule Developer Help file deployed with InRule. The cache resides with the SDK runtime, so it will be cleared every time the application pool recycles. Once the cache is cleared, the first call to execute a ruleset or apply rules will "take a hit" because the rule application is retrieved, compiled and added to the cache again.
Here is a quote about recommended IIS settings:
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.
If you want to avoid the lightweight checks for new revisions (default is every 30s), then you can increase the interval by using a web.config parameter (refreshInterval) or ruleApp.SetRefresh in your code. This means that any new revisions are ignored until the refresh interval expires and the cached rule application revision is used. You may also want to change your processes and have weekly update windows when you force a cache refresh by recycling the application pool.
To avoid the cold start for client calls, you can choose to pre-load the cache by making rule engine calls that hit the rule applications you need in the cache, as soon as the cache is cleared and before client calls.
If you are not working with a custom service hosted in IIS and calling irSDK in-process but calling irServer Rule Execution Service out-of-process instead, please look for "irServer - Rule Execution Service" -> "Caching Behavior" in the help file.