Virtual directories are touted for their flexibility, but the technology isn't known for its speed. A virtual directory adds an extra layer of software and intermediate TCP/IP hop. Factor in the dynamic transformation, the join of data from disparate directories and the reorganization of the underlying namespaces, and a virtual directory will always be slower than the sources it virtualized.

But in critical operations such as identification, authentication and authorization, a virtual directory needs to provide guaranteed fast access to information. In many cases, the virtual directory needs to read faster than underlying sources can deliver. It can accomplish this through caching mechanisms.

A virtual directory can be divided into two layers. The front end handles the Lightweight Directory Access Protocol (LDAP) or another standard protocol, and the back end maps and transforms the data from the virtualized sources (directories, databases and/or applications). The back end represents the virtualization layer, and the virtual directory's performance depends on the scalability and speed of the back end.

A virtual directory needs access to the underlying virtualized data sources. Without a caching strategy, a virtual directory acts as a proxy, forwarding the calls to the underlying sources. Even with the best optimization at the front-end level, a virtual directory will deliver only a fraction of the speed of underlying sources.

There are essentially two forms of cache: in-memory and persistent.

In-memory cache. Recent queries and their results are stored in memory. An in-memory cache will work when the volume of entries and the variety/complexity of the queries are modest. The success of this approach is based on exact syntax matches for a query. To benefit from in-memory cache, the query must incorporate the same search by the same user with the same type of search filter. If one of these parameters is different, the system may have to go back to the original source, even if some entries are already in the cache. For example, the same query but with a different user will qualify as a different query and not benefit from the cache since each user can have different access rights and can get different results.

Disk-based cache, or persistent cache. An image of the virtual entries is stored in the local virtual directory store. The cache no longer depends on memory size and can provide fast recovery in case of failure. The entire virtual tree can be cached this way, and a huge volume of entries can be supported, allowing for full data synchronization. To fully support the range and detail of all possible queries while delivering the same speed as the best Lightweight Directory Access Protocol server, the persistent cache must be a full LDAP Version 3. In fact a persistent cache is equivalent to a materialized view of a complex directory tree stored in an LDAP format and transparently refreshed by polling or pushing events at the level of the data sources. The challenge and complexity reside in the automation of the refresh mechanism: Each change at a data source has to be captured, transformed and dispatched to the right object, which could be distributed or joined across many virtual branches.