This article supports you in dimensioning and configuring MetaDirectory if, for example, there are severe delays or timeout when searching for contacts or resolving phone numbers in ProCall from MetaDirectory, even though the contact data is available in MetaDirectory.

It is not possible to make a general statement about the causes of delayed results in a MetaDirectory search, as this depends on the respective system environment. The following notes are empirical values to help you achieve correct dimensioning for contact search and replication.

Procedure

Is the MetaDirectory properly sized for the amount of data and number of users?

In this context, the following questions often arise:

  • How many records can be replicated with MetaDirectory?
  • How many users can access MetaDirectory?
  • How should the system be dimensioned?
  • How do the different MetaDirectory versions (Standard, Professional, Enterprise) differ in this respect?

Unfortunately, we cannot make any concrete statements on this, as it always depends on the respective conditions in the customer environment. Of course, it relates not only on the number of data records, but also on their size (data record with 2 attributes vs. data record with 50 attributes). If there are massive speed losses and these cannot be solved by configuration, it is necessary to operate several MetaDirectories in parallel and distribute the nodes administratively to the (ProCall) clients (i.e. not via the UCServer).

In principle, the different versions (Standard, Professional, Enterprise) of MetaDirectory should not differ significantly in performance. However, it can be assumed that Enterprise will lose some performance due to data/user mapping.

Customer environments with 150 sales employees (i.e. intensive ProCall use) with 500,000 data records could be brought into operation without any problems after initial complaints about poor response up to the timeout and crash of MetaDirectory by a reasonable configuration of the search fields and adaptation of the field types used. We have already replicated 2 million data sets and had no problems with the search afterwards.

An appropriate equipment with main memory clearly > 2 GB (alone for the MetaDirectory) can certainly not hurt, many processor cores however bring with the present architecture of the server nothing.

It is important to clarify exactly what is being searched for and in which MetaDirectory fields, and that these fields are indexed by selecting them in the search wizard in MetaDirectory Administrator. Furthermore, it is essential to select the correct field type under Database Fields in the MetaDirectory Administrator, since the search algorithms are optimized differently for telephone numbers or name fields, for example.

Caution: The blanket activation of all database fields for the search affects performance!

A sensible approach, in addition to correct configuration, is certainly by step-by-step commissioning (increase in the number of users) while observing system behavior.