LDAP Capacity Calculator

database = entries × average entry size × (1 + index overhead); throughput = worker threads ÷ average search service time. Directory throughput is a queueing problem: each worker thread handles one search at a time, so capacity is threads divided by service time. Service time in turn depends on whether the search hits an index and whether the entry is already in cache, which is why the cache target drives the memory figure.

Every authentication, group lookup and application login hits the directory, so an under-sized entry cache turns a 1 ms indexed search into a disk read and takes login latency with it.

This calculator takes 7 inputs: Entries in the directory, Average entry size, Index overhead, Share of the database you want cached, Peak search rate, Average search service time, Worker threads per server. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

An unindexed search becomes a full scan of the entry set, so its service time jumps from around a millisecond to seconds while it holds a worker thread the whole time. A handful of concurrent unindexed searches can consume every thread and stall authentication for the entire estate.

Enough to hold the working set — the entries actually being looked up — which is usually far smaller than the whole database. Caching 60% of the database, the default here, is a common starting point; measure the cache hit ratio and raise it until hits plateau above roughly 95%.