---
title: "From hours to minutes: Optimizing Red Hat Developer Hub performance testing with immutable LDAP images"
description: "Red Hat Developer Hub performance testing became slow and unreliable as runtime generation of large user and group catalogs stretched environment setup and introduced synchronization failures. Previously, the framework created entries through serialized Keycloak Admin REST API operations, then waited for paginated synchronization into the Developer Hub database; concurrency could not eliminate timeouts, rate limits, or incomplete catalogs. The replacement uses immutable, pre-built LDAP container images selected by an RBAC_POLICY-USER_COUNTu-GROUP_COUNTg convention, with slapadd loading seed data directly into offline LMDB files in a multi-stage build. LDAP starts with 10,000-plus indexed users, while Keycloak serves as an authentication gateway and Developer Hub waits for its initial catalog sync. Reported population time fell from 22-plus hours to 2 minutes 8 seconds for 10,000 users and 150,000 groups, while the immutable approach made tests deterministic, reduced flaky failures, stabilized baselines, and enabled larger reproducible scenarios."
---

# From hours to minutes: Optimizing Red Hat Developer Hub performance testing with immutable LDAP images

[Red Hat](https://yomu.fyi/company/red-hat) · Shashank Kestwal · Sep 17, 2026

**Type:** Benchmark

## Summary

Red Hat Developer Hub performance testing became slow and unreliable as runtime generation of large user and group catalogs stretched environment setup and introduced synchronization failures. Previously, the framework created entries through serialized Keycloak Admin REST API operations, then waited for paginated synchronization into the Developer Hub database; concurrency could not eliminate timeouts, rate limits, or incomplete catalogs. The replacement uses immutable, pre-built LDAP container images selected by an RBAC\_POLICY-USER\_COUNTu-GROUP\_COUNTg convention, with slapadd loading seed data directly into offline LMDB files in a multi-stage build. LDAP starts with 10,000-plus indexed users, while Keycloak serves as an authentication gateway and Developer Hub waits for its initial catalog sync. Reported population time fell from 22-plus hours to 2 minutes 8 seconds for 10,000 users and 150,000 groups, while the immutable approach made tests deterministic, reduced flaky failures, stabilized baselines, and enabled larger reproducible scenarios.

## Context

The performance testing framework needed large, repeatable volumes of Red Hat Developer Hub users and groups to exercise catalog-dependent behavior, RBAC, and concurrent active-user scenarios. Runtime provisioning through Keycloak became a bottleneck and introduced failures during synchronization, so the team measured the effect of moving catalog data into pre-built LDAP images.

## Approach / What changed

The team replaced runtime Keycloak Admin REST API generation with immutable LDAP container images. A multi-stage Containerfile uses slapadd to populate OpenLDAP database files offline from seed.ldif, then copies those files into the runtime image. Images are selected using the RBAC\_POLICY-USER\_COUNTu-GROUP\_COUNTg convention; LDAP supplies the catalog data while Keycloak functions as an authentication gateway.

## Takeaways

- For 10,000 users and 150,000 groups, reported population time dropped from more than 22 hours to 2 minutes 8 seconds after switching to pre-built LDAP data.
- Using slapadd offline bypasses the network layer and writes directly to LMDB database files, avoiding per-entry protocol validation during image construction.
- Adding the memberOf attribute pre-computed graph relationships for read-heavy catalog ingestion, reducing the need for expensive N+1 queries.

## FAQ

### Why did concurrent Keycloak API workers fail to solve the provisioning bottleneck?

Each user still required a serialized chain of Keycloak Admin REST API operations. Large runs also encountered network timeouts and rate limits, and the subsequent paginated synchronization could leave the catalog incomplete.

### How are the LDAP images populated efficiently?

The build uses slapadd while OpenLDAP is offline, writing seed data directly into LMDB files instead of importing entries through the online protocol. A multi-stage build then copies the populated database into the runtime image.

### What changed for Keycloak and catalog synchronization?

Keycloak shifted from being the catalog's data source to serving as an authentication gateway. LDAP starts with the pre-indexed users, and Red Hat Developer Hub waits for the first catalog synchronization to complete.

**Tags:** [LDAP](https://yomu.fyi/topic/ldap), [Performance](https://yomu.fyi/topic/performance), [Red Hat Developer Hub](https://yomu.fyi/topic/red-hat-developer-hub)

- Source: [Red Hat](https://developers.redhat.com/articles/2026/09/17/optimizing-red-hat-developer-hub-performance-testing-with-immutable-ldap-images)
- Source URL: https://developers.redhat.com/articles/2026/09/17/optimizing-red-hat-developer-hub-performance-testing-with-immutable-ldap-images
- Ingested by Yomu: 2026-09-17T14:06:17.964Z

[Read original post](https://developers.redhat.com/articles/2026/09/17/optimizing-red-hat-developer-hub-performance-testing-with-immutable-ldap-images)