Search
Welcome to M-Files Empower – our new support experience. We'd love to hear what you think!Give feedback

Last updated on 30 March 2021

Admin
Search

Overview

This document describes how to estimate the IDOL environment size. 
NOTE ! This document is valid for M-Files 20.9.x and beyond and IDOL version 12.x and beyond.
 

Single installation or a cluster

If you have less than 1 million objects, you can use a single installation, which is just one IDOL engine without DIH, DAH and Daily components. Still, we recommend to use a cluster with two backend engines even if there would be less than one million objects. A cluster is basically as easy to install as a single engine, it can be installed completely on one server, and it can be scaled up in the future. 


Cluster: One engine per 1 million objects

In a cluster setup we can have x number of engines (in practice 20 engines is considered to be the maximum). Each engine will handle up to 1 million objects that have MetaData and FileData.
If you have pure MetaData objects (i.e. no files in them), then you can multiply the amount by three, meaning a maximum of 3 million objects per engine. Make sure you really have only MetaData objects and do not get greedy on the calculation or it will degrade IDOL performance.


How many engines per disk and per server?

This depends a lot on the server, especially its I/O capabilities. The more engines you use, the disk activity you generate. A good rule of thumb is to optimally use 1 engine per one disk and 5 engines per server. 

3 engines per disk at maximum.

10 engines per server at maximum, but note that performance will be affected at least during migrations. Example:
  • Azure Cloud server 
  • Premium SSD disk with IOPS limit 2300 and Throughput limit 150 MB/s
  • 10 backend engines
  • Indexing over 20.000 objects which will result indexing directly into the backend
  • Manually added file will be searchable after 2-3 hours 
  • Conclusion: Although everyday working scenario is OK for this environment, migrations will severely affect usability. That said, in these kinds of environments you should consider carefully when to do additional migrations or changes that trigger a lot of indexing operations (e.g. NACL changes).


How much disk space?

The needed disk space is highly dependent on the indexed material. Normally, we are talking about objects using both MetaData and FileData. In that case and if talking about normal office documents, the index ratio should be calculated by 10% of the FileData size to be on the safe side. 150 Gb of FileData (=files), equals roughly 15 Gb of index data. 
Obviously, MetaData-only objects use a negligible amount of disk space compared to that, so usually there is no need to calculate anything with environments having mostly MetaData-only objects. 


Disk space and IDOL compaction

One additional thing to keep in mind is the compaction routine of IDOL. It might take up to 100% of extra space, so in the previous example case that would be 30 Gb.
 

Still need help?