I was deep in a performance tuning session yesterday, trying to figure out why some of our user lookup workflows felt sluggish, even with decent hardware. We're using PingDirectory for a customer-facing app, and those extra milliseconds on search operations really add up. After comparing our configs against some internal benchmarks, I stumbled on a parameter that isn't discussed much in the standard docs, and it made a **noticeable** difference.
It's the `search-entry-cache-size` property in the `entry-cache` configuration. Ours was set to a pretty conservative default. After some cautious testing, we bumped it up to better match our active working set of user entries. The idea is to cache entire entries (not just IDs) in memory for faster retrieval on frequent searches.
The key for us was finding the right balance. We didn't want to just max it out and bloat memory usage. Here's what we considered:
* **Profile your most common search filters** (like `uid=` or `mail=`). Ours were largely specific to a few attributes.
* **Monitor your entry cache hit ratio** before and after. The `ds-entry-cache` monitor gives you this.
* **Adjust gradually** and measure the impact on both latency and GC activity.
For our use case, increasing the cache size reduced our average search time for those high-frequency lookups by about 30-40%. It's not a magic bullet for all slowdowns, but if you haven't looked at this, it's worth checking. Has anyone else played with this or other tuning knobs for search performance? I'm curious if there are other "hidden" settings for heavy read operations.
– Amanda
Show me the accuracy numbers.
Nice find on the `search-entry-cache-size`! That monitoring step is crucial. We had a similar journey but hit a snag where a higher cache size actually hurt performance for our bulk export jobs - the cache was holding onto too many entries that weren't being re-read. Tuning it really is a per-workload thing.
I'm curious, when you profiled your common filters, did you notice any specific attribute patterns that seemed to benefit the most from being cached? For us, it was `employeeNumber`.
Always testing the next best thing.
Good call on profiling the filters. That's where most teams mess up - they cache everything and wonder why memory balloons.
For us, the biggest wins came from caching entries with `telephoneNumber` and `manager`. Not because of the attributes themselves, but because those searches were always followed by a full entry read for display. The cache prevented a second disk hit.
Your point about bulk export jobs is critical. We set up a separate, smaller cache for background processing tasks. Trying to use one cache for both real-time lookups and batch processing is a recipe for thrashing.