Web UI takes 30-60s to load

roble · May 2, 2025, 9:13am

We’re running Chirpstack4 on Kubernetes. The initial web UI login screen takes 30-60s on average to load (see attachment). Once logged in the site very responsive.

I’m not familiar with Rust to tell whether or not the use of Router::new().fallback() to serve static content (ie react js files) is the issue.

github.com/chirpstack/chirpstack

chirpstack/src/api/mod.rs

master


      
          let web = Router::new()
              .route("/auth/oidc/login", get(oidc::login_handler))
              .route("/auth/oidc/callback", get(oidc::callback_handler))
              .route("/auth/oauth2/login", get(oauth2::login_handler))
              .route("/auth/oauth2/callback", get(oauth2::callback_handler))
              .fallback(service_static_handler)
              .into_service()

Axum fallback performance issue `Router::nest` has poor performance on 0.6 · Issue #1624 · tokio-rs/axum · GitHub
Updated docs on fallback: Router in axum - Rust

brocaar · May 2, 2025, 9:34am

I’m not able to reproduce this. I think what the link describes is that using fallback without any other routes is not not a good idea. However, this is not the case in the ChirpStack code. The static handler in the fallback must be used, when the other routes do not match.

The reported issue from your link:

The old code manages approximately 24 500 req/sec in a reverse proxy use case.
The new code and so on manage approximately 16 500 req/sec, which is a huge drop.

The ChirpStack UI doesn’t get close to these numbers to load the web-interface So even if the fallback would cause some performance issues, it would not cause the UI to load in 30-60 seconds.

roble · May 2, 2025, 10:20am

I forgot the attachment. As mentioned, just the initial 4MB react js that is slow to load. Everything is very fast once logged in. Anyhow, I’m going to re-create a local setup with docker-compose to see if I can reproduce it.