Skip to content

Keycloak Startup time regression #19858

Description

@tjwald

Is there an existing issue for this?

  • I have searched the existing issues

Describe the bug

In previous releases there was startup time regression in keycloak and was attributed to issues in other areas.
Those issues are reported to have been fixed, and yet we still see 3+ minutes startup time for Keycloak.

This slowdown is hurting our e2e tests in CI. We prepull the image before aspire start so the only cost is the actual container startup time.

I tried to reproduce it with a minimal apphost, and it only took 23 seconds, so probably something about the orchestration of our apphost is making the keycloak startup slow.
In local development I can see that it takes a while before aspire tries to start the docker, and even after it is started it takes a long time.

Expected Behavior

starting keycloak takes 23 seconds in an empty apphost - the startup time in a larger apphost shouldn't be substantially longer (less than 1 minute).

Steps To Reproduce

I created an empty apphost with only keycloak and it started up in 23 seconds.
In our large apphost it took over 3 minutes in CI, and locally 2 minutes.

Exceptions (if any)

No response

Aspire doctor output

➜ aspire doctor

Aspire Environment Check
========================

Aspire
  ✅ Aspire CLI version 13.5.3 (channel: stable)
  ✅ Developer Control Plane (DCP) connection health checks succeeded

AppHost
  ✅ AppHost version 13.5.3 (apphost.cs)

.NET SDK
  ✅ .NET 10.0.203 installed (arm64)

Container Runtime
  ✅ Docker v29.1.3: running (auto-detected (default)) ← active

Environment
  ✅ Operating system: macOS 15.7.7
  ✅ HTTPS development certificate is trusted

Development Tools
  ✅ Aspire extension for VS Code is installed

Summary: 8 passed, 0 warnings, 0 failed

Aspire CLI Installations
========================

╭───────────────────────────────────────────┬─────────────────────────────────────────────────┬─────────┬───────────┬─────────────╮
│ Path                                      │ Version                                         │ Channel │ Route     │ PATH status │
├───────────────────────────────────────────┼─────────────────────────────────────────────────┼─────────┼───────────┼─────────────┤
│ /Users/twald/.aspire/bin/aspire (current) │ 13.5.3+b5f143315ffb6968ea939a9978797a5b20e4c688 │ stable  │ (unknown) │ active      │
╰───────────────────────────────────────────┴─────────────────────────────────────────────────┴─────────┴───────────┴─────────────╯

Anything else?

No response

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area-integrationsIssues pertaining to Aspire Integrations packagesneeds-area-labelAn area label is needed to ensure this gets routed to the appropriate area ownerstriage:bot-seenAspire triage bot has seen this issue

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions