O3 Server uses resources in an efficient way. The efficient way to use O3 Server memory allows for flexibility and scalability
Overview
Detailed tests have proved that a considerable amount of time is spent every time a cube is opened from O3 Server. This is due to the physical loading of the metadata, as well as to the establishment of data structure. Then, why not reuse the work already done? This simple question and its answer lead us to the creation of a cubes cache resident in O3 Server. This cubes cache keeps cubes open even when no users are connected to them.
These cubes can be monitored using O3 Server Administrator, in the sub-tree "Open Cubes"
Through O3 Server, it is also possible to control the number of cubes maintained in this state (open, not connected). This parameter is called "Number of Cubes in cache) and is found in the cube services editor, along with the "Status" parameter.
A cache size of n cubes, indicates that, at the most, n cubes will be kept open without connection, waiting for new users to use them again. As these unused cubes use up memory resources that might be required by other cubes, when the cache is full, they will eventually be closed and discarded.
With O3 Server Administrator, it is always possible to force the elimination of any cube in the cache, just by removing it from the "Open Cubes" subtree.
Loading cubes on Server startup
Another interesting feature is the "Load priority on startup". This parameter can be set for each cube published in O3 Server by means of the O3 Sever Administrator. It is found in the same editor where the path to the local file is entered.
The purpose of this parameter is to suggest O3 Server that each time it is uploaded, certain cubes should be automatically loaded. This ensures that, when the first user logs in to any of these cubes, all the initial load process has already been done, thus reducing the time of the initial query considerably.
This parameter can take one of the following 6 values:
- None
- Very low
- Low
- Normal
- High
- Very High
"None" is the default value for new cubes and it means that the cube will not be loaded on server startup.The other values help O3 Server sort out the loading sequence. A maximum of n cubes can be loaded on startup, with n being the size of the cache mentioned above.
How does the Cubes cache work?
The main feature is that memory resources are automatically distributed among open cubes, automatically closing cubes with no connections if more memory is needed.
Three variables are used to control its operation: a system property to specify the maximum available memory, the minimum number of memory blocks the cubes need to run, and the maximum number of blocks the cubes can use in the memory.
The aforementioned system property is "ideasoft.o3.pool.totalMaxCache", with a default value of 25000 blocks. This means that by default, O3 Server will use only up to 25000 memory blocks to distribute among all its cubes, whether they have open connections or not.
The minimum number of blocks necessary for the cubes is calculated by adding up the minimum number of blocks needed to open each of them. This resulting number must be smaller than the one specified in the previous property.
Each time a new cube is going to be used, the minimum is recalculated and if the result exceeds the allowed maximum, and there are not any open cubes without connection, the request is denied. In these situations, a log is generated so that the Server Administrator knows what is going on. If on the contrary, there are open cubes without connections, they are closed, thus freeing resources.
The maximum number of blocks for each cube is used to distribute the available memory among open cubes. The criteria used for this distribution is that a greater maximum, means more memory with regards to other open cubes.
The minimum number of blocks and the maximum allowed are specified at the time of the design, with O3 Designer, through the use of the "Min Cache" and "Max Cache" parameters. When the cubes are published in O3Server, these parameters can be modified at the time of execution, to control the amount of memory each cube receives.