Performance Settings

Even though Ometa strives to make the framework as performing as possible, some settings can be managed better by the users because they are either out of the hands of Ometa or dependent on the kind of solution being build.

Note

The settings below are what is believed to be good practices. However, please be aware that every solution can be slightly different and as such some values may need to be tweaked depending on what is required.

Basically 2 scenarios are described:

Administrative application, having a 9-to-5 use;
Factory floor application, running 24/7.

Apart from these scenarios it is also necessary to keep other items in mind like scheduled jobs for example. If it is not certain which scenario to choose, just start out with the administrative application scenario and adapt the settings on an as-needed basis later after gaining more experience with the behaviour of the solution and environment.

IIS Site Idle Time-out

Together with the application pool recycling settings, this will have an impact on the duration of the very first calls of ADM on a working day. By default the IIS site idle time-out is 20 minutes. This means that after 20 minutes, an IIS site will go into sleeping mode and needs to wake up again. It's the "waking up" process that causes major delays on calls from ADM.

Changing this value depends entirely on one thing: will the additional initial startup time cause any friction to users? For administrative application the initial startup time may happen twice, once in the morning and again after lunch break. If there is a wish to avoid the second startup delay in the afternoon, it could be a good idea to increase the idle time-out value to 60 minutes if, for example the average lunch break only takes 30 minutes.

In the scenario of the factory floor application, the continuous access from ADM to the framework e.g. every minute or few minutes, may mean that the idle time-out is never reached and a change to the value isn't therefor strictly required.

When there is a need to ensure that the IIS sites are always awake for high availability, there are 2 ways to achieve that. Either raise the setting to a very high value like 1740 minutes (= 29 hours), or set it to 0 effectively disabling the sleeping mode action. For more information, consult the page App Pool set idle time out IIS Server.

The setting can be found in the Advanced Settings section of an IIS site. On the screenshot the value is set to 1740 minutes.

IIS site idle time-out

IIS Application Pool Recycling

By default an IIS application pool is set to recycle every 29 hours. This recycling process ensures that any unknown memory leak can't cause a server crash and also frees up memory that is currently allocated to cached data.

The default configuration of a 29 hour interval means that a recycle might happen during a peak in your production environment. This also means that users requesting data during the recycle or immediately after, will suffer a severe performance penalty. This penalty is the same as the penalty caused by the site idle time-out setting because the Windows process for the IIS site has be started again. Nonetheless just as with the idle time-out setting, if the usage scenario e.g. administrative application, has no issues with the additional startup time it may be better to keep the default settings.

But for scenarios like a factory floor application, this should be adapted to minimise the impact of application pool clean up. First, a default recycling time should be configured instead of an interval and secondly, several jobs in the framework has be scheduled to start the Windows processes for each IIS site immediately after the recycle process. Which recycling times and job schedules to apply really depend on the load and time of use of the framework solution in general.

Step 1: Setting the Recycling Time

Ometa advices the following recycle times according scenario:

Administrative application: use a single fixed recycle time for all three application pools, e.g. 3 am.
Factory floor application: use a different recycle time for each application pool to space out the downtime of each service. This interval can be in the range of 10 minutes to 30 minutes difference. An example with 15 minutes between every recycle action:
- Ometa Core Service: 2 am
- Ometa Authority Service: 2:15 am
- Ometa Generic REST Service: 2:30 am

Select the right recycle time(s). Ensure that no scheduled tasks (synchronizations, method jobs, Windows scheduled tasks, ...) can interfere at the chosen time.
For each application pool related to the Ometa Software Suite, open Recycling....
Uncheck the interval checkbox and set a specific time. In the example below, the recycle time is set to 3 am.
Save the changes.

Step 2: Dummy Call to the Services

Sending a dummy call to the services will awaken them. Beware! Depending on the scenario chosen in the first step, several actions in this step must be repeated for each service if difference recycle times were applied to each service.

Create a batch file somewhere on the disk with the following contents. This will call the three Ometa IIS sites on their root (use the urls that apply to your services):
```
curl -s -o nul https://myauthorityservice:port
curl -s -o nul https://mycoreservice:port
curl -s -o nul https://mygenericrestservice:port
```
In the case of multiple recycle times, put each line into its own batch file.
In the Ometa Software Suite, create a new object called KeepAlive (change the name if needed/preferred).
Inside the object, create a new method Awaken IIS Services (change the name if needed/preferred), or when using different recycle times, create 3 different methods:
- Awaken IIS Core Service
- Awaken IIS Authority Service
- Awaken IIS Generic REST Service
Set the template of the method or methods to OS.
Set the interface script of the method to the full path of the batch script, or in case of multiple methods use the full path of the corresponding batch script related to that specific method.
Ensure that you have an OS profile that this method or these methods can be executed on.
Go to the Method Jobs tab of the Ometa Business Connector Configurator.
Create a new method job called Awaken IIS Services or multiple method jobs Awaken IIS Core Service, Awaken IIS Authority Service and Awaken IIS Generic REST Service.
Configure the method(s) created similar to this screenshot:

Note
If multiple methods were created, repeat this step for each one of them. Make sure to select the correct method for the accompanying method job.
Create a schedule to run every day. Set it to 2 to 5 minutes after the configured recycling time(s) as selected in step 1.
Save all the changes.

After setting both the IIS site idle time-out and application pool recycling scheme, together with the scheduled job(s), the IIS sites of the Ometa Software Suite should always be available and ready to respond to any incoming requests.

Service Startup Retry

Every Ometa IIS service (Core, Authority and Generic REST) has some built-in retry mechanism during the startup phase, so that when a database or one of the other Ometa web services isn't available, the IIS service will try again for a couple of times with a short delay between each attempt.

Both the Authority and Generic REST services have retry procedures that by default retry dependency access maximum 5 times with 5 seconds delay in between. The Core service has different retry procedure as it only requires database access right after the startup of the process.

Those retry settings can be modified by adding some properties to the general or corresponding appsettings.json files of the respective services. Define the following properties:

{
  // ...
  // Other JSON Settings
  // ...

  "StartupMaximumRetryCount": 5,
  "StartupRetryWaitInterval": 5
}

Name	Default Value	Description
StartupMaximumRetryCount	5	The maximum number of attempts taken during the service startup to access a dependency.
StartupRetryWaitInterval	5	The interval time, in seconds, between retry attempts.

Important

This is not a fail-safe procedure. If some dependency remains unavailable, the startup of the web service will still fail after all. It is helpful in case a web service is starting up again after a recycle and for some reason a dependency is briefly unavailable, e.g. a couple of seconds.

For longer outages, a manual intervention may still be required to kickstart the web services again.