Checklist
I have read intro post: https://community.passbolt.com/t/about-the-installation-issues-category/12
I have read the tutorials, help and searched for similar issues
I provide relevant information about my server (component names and versions, etc.)
I provide a copy of my logs and healthcheck
I describe the steps I have taken to trouble shoot the problem
I describe the steps on how to reproduce the issue
Self-hosted Passbolt CE 5.14.3-1-ce (Docker), MariaDB 11.8, behind Traefik v3.1 with HTTP/2 confirmed via ALPN. Client: Android app (fork of mobile-passbolt-android, master branch base), Xiaomi 14 Ultra, on WiFi throughout testing.
Symptom: Every cold start (app killed, then reopened) shows the loading bar for 15–25 seconds before the resource list is usable, even though nothing changed server-side. This matches what’s described in Extremely slow performance on Android almost exactly — staff there confirmed the app makes ~13 sequential API calls on sign-in, and users reported 9–25s delays depending on network.
What I ruled out with direct measurement, not guesswork:
Server load: idle (4 vCPU / 3.8GB RAM box, load average ~0.04, MariaDB Slow_queries = 0)
Client-side decryption: captured via adb logcat — full resource-list decrypt took 0.83 seconds, not the bottleneck
HTTP/1.1 fallback (root cause in a different thread): checked via openssl s_client -alpn — my server correctly negotiates h2
A reported /users.json slow-query pattern (dependent subquery on action_logs, GET /users.json is 100x slower) — reconstructed and timed the same query against my DB: 290ms. Doesn’t apply here (I only have 5 users, vs. 62 in that report)
What I found instead: each API call in the sync sequence pays a large, roughly fixed ~2.4–4 second cost regardless of response size. Confirmed by testing page size 3000 vs. 250: dropping to 250 (6 sequential pages instead of 1) made total resource-fetch time worse — 25.3s vs. 6.7s — because it’s mostly per-request overhead, not per-byte transfer time. This lines up with the architecture-level issue mentioned in the thread above (staff said broader performance work is on the roadmap “post-architecture migration,” ~80% complete at the time).
Fixes I’ve already tried on the client (all real, none solved the core issue):
Parallelized the ~8 independent network fetches in the full-data-refresh pipeline (previously fully sequential, upstream even had a // TODO start multiple async where possible)
Debounced redundant back-to-back full refreshes (15s window)
Raised the in-memory passphrase cache TTL from 5→30 minutes, so a full resync isn’t triggered as often
Stopped the session-key-cache upload (a write-behind step benefiting other devices, not this one) from blocking the “sync finished” signal
All of these reduce how often the slow path runs and shave one round trip off its tail, but none touch the actual multi-second-per-request cost, since that appears to be inherent to the current sequential-call architecture rather than anything fixable client-side.
Question for the team: is there an ETA or tracking issue for the architecture migration mentioned in the other thread? And is there anything server/proxy-side (Traefik config, PHP-FPM pool sizing) worth checking that wouldn’t show up as slow from curl but would from a real mobile client making the full ~13-call sequence?