Configuring how AR System server manages cache
This topic outlines how you can optimize the time it takes an AR System server to load information into the cache and how you can manage how the server uses memory.
Setting the Preload Tables Configuration option
The AR System server loads the cache from the database at the following times:
- (All servers) At server startup
- (Non-administrative servers in server groups) At runtime whenever the administrative server in a server group signals that it made a change to the cache
The Preload Tables option allows the server to make better use of system resources, such as multiple CPUs and network bandwidth, when loading the cache during server initialization and in server group operations. Using the Preload Tables option, can greatly reduce server startup time and the time required for cache reloads in a server group, but it requires that larger amounts of memory are available to the AR System server. This option preloads metadata from database tables into the server cache. The metadata includes field definitions and display properties.
Setting preload threads and preload segments
When the Preload Tables Configuration option is off, a single thread loads information directly from the database into the cache.
When the Preload Tables Configuration option is on, the server uses multiple threads running in parallel (preload threads) to load data in segments from database tables into memory.
Each preload segment represents one or more schemas (forms). For example, if you have 3,000 schemas and you configure 300 preload segments, each segment represents 10 schemas. In that case, a preload thread reading a segment of the field definitions table would process field definitions for 10 schemas.
Because all forms do not have the same amount of data, configuring multiple preload segments for each preload thread enables threads to balance their load effectively. For example, if you configure only one segment per thread and some threads finish before others, the finished threads have no more work to do. But if you configure multiple segments per thread, as a thread finishes loading one segment, it can begin loading another.
Each thread uses a separate connection to the database. Any thread can load any segment. When a thread finishes loading a segment, it begins loading another segment. When all segments have been loaded, the thread terminates.
After the segments are loaded, the server populates the cache by reading the information from memory instead of directly from the database.
You can configure the server to use preload threads at either of these times:
- Only at server startup
- Whenever the server loads its cache from the database
To configure preload threads, use the Preload Tables Configuration option on the Advanced tab of the Server Information form.
The Preload Tables Configuration option is on by default for 64-bit UNIX or Linux servers. It has the following default settings:
- Preload Tables at Init Only—No
- Number of Preload Threads—20
- Number of Preload Segments—300
To turn this option off, set Number of Preload Threads to 0. This option is off by default for Windows servers.
Determining the optimum preload settings
Using preload threads can greatly reduce server startup time, but it temporarily increases memory consumption.
If you use preload threads, start with the following settings:
- Ten preload threads
- One preload segment for every three schemas (forms) on the server
To determine the optimum settings in your environment, vary the number of preload threads and segments to find the configuration that produces the fastest cache load time. Adjusting the number of preload segments balances the load between the preload threads.
Such testing also helps identify the amount of preload memory required in addition to cache memory.
Initial testing of this feature at BMC Software indicates that a Unicode server with the full BMC Helix ITSM and all language packs installed consumes about 500 MB more memory at initial cache load when it uses preload threads than when it does not use preload threads.
When determining whether to use preload threads and how to configure them, consider the following factors:
The amount of memory available to the AR System server at startup and at runtime.
- Whether the server is part of a server group. Non-administrative servers in a server group load the cache from the database whenever server object changes occur. These servers derive the most benefit from using preload threads for all cache loads.
- The number of database connections available. Each preload thread uses one connection to the database.
Caching display properties
Display properties include the background images used in forms and the display properties of each form field. Server display properties are display properties for forms and fields used in server workflow only. The Display Property Caching option enables you to control how the server caches display properties. This feature can be used alone or in conjunction with preload threads.
The Display Property Caching option provides the following settings:
- Cache Only Server Display Properties (Default)—Memory usage for the cache is smaller, but when a client opens a form for the first time, response time is slower. This delay occurs because the server must load the display properties from the database at that time.
- Cache All Display Properties—Server response time is faster when a client opens a form for the first time, but the memory space required for the server cache is larger.
To specify how display properties are cached, use the Display Property Caching option on the Configuration tab of the Server Information form.