Forcing app data stay in engine memory via idle QIX WebSocket sessions to eliminate cold-load latency.is this a safe long-term ?any downsides?
Problem: Our Qlik Cloud apps has long first-load times after periods of inactivity (cold start), which hurts the user experience when someone opens an app after it's been idle.(App takes little more than 2 minutes to open even after optimization)
What we built:A small external service (Go, using enigma-go) that, for a configured list of apps:
Opens a QIX WebSocket session per app and callsOpenDoc(with data, notnoData), so the app's data gets loaded into engine memory.
Holds that session open rather than closing it right away.
Periodically (e.g. every 30s–few minutes) sends a lightweight, session-level call (Global.EngineVersion) over thesameconnection — not a new connection each time — purely to detect if the socket silently dropped, and reconnect if so.
Only disconnects deliberately outside configured business hours, to stop consuming engine capacity when nobody needs the app to be fast, then reconnects when the window reopens.
The goal is purely to keep the app's data resident in engine memory so real users hit a warm app instead of triggering a cold load. We're not touching charts, objects, or expressions — just the app-level data load and an idle session.
Question :
Besides the obvious engine memory consumption from holding these sessions/data open, are there other side effects we should be aware of with this approach on Qlik Cloud? For example:
Any impact on licensing/session counts we should watch for?
Any risk around holding long-lived idle WebSocket sessions from the engine's or gateway's perspective (timeouts, rate limiting, etc.)?
Is there a more "supported" or intended way to achieve this (e.g. official pre-load/keep-warm features) rather than an external keep-alive client?
Thanks for the detailed write-up — it's great to see the depth you've gone into here, and we appreciate you sharing the approach with the community.
You're right that app opening involves loading data into engine memory, and for larger or more complex apps, that can add some time — this is by design given how the associative engine works, but we absolutely understand it affects the experience when someone opens an app after it's been idle.
To be transparent: we don't offer an official pre-load / keep-warm capability in the product today. Keeping app data resident in memory indefinitely isn't something we can offer "for free" from a cloud platform perspective — memory is a shared, finite resource across tenants, so we're actively investigating how we could offer this as a proper, monetizable capability going forward. More details will be shared on that as it develops.
In the meantime, there are a couple of things already in motion that should help with the underlying problem:
New CPU core types are being rolled out on the backend for all tenants, at no additional cost. In our testing, this has shown up to a 20% improvement in performance for app opening and other CPU-heavy tasks.
A preview mode is planned for Q3 2026, which will let users see a selectable sheet within seconds, even while the full app is still loading in the background.
So the direction we're heading in should meaningfully reduce the pain point you're describing without needing an external keep-alive service.
One flag for you: the approach you've built (holding idle QIX WebSocket sessions open) works today, but it's not an officially supported pattern, and there's a real chance it could break or become unnecessary once we introduce a proper pre-loading capability. Wanted to raise that now so it doesn't come as a surprise down the line.
If cache warming / app pre-loading is something you'd find valuable as an official feature, it'd be great if you (and anyone else reading this) could submit or upvote an idea on Qlik Ideation — that helps us prioritize it against other roadmap items and gives us something concrete to point to internally.
Appreciate you raising this, and happy to update the thread as we have more to share.
Thanks for the detailed write-up — it's great to see the depth you've gone into here, and we appreciate you sharing the approach with the community.
You're right that app opening involves loading data into engine memory, and for larger or more complex apps, that can add some time — this is by design given how the associative engine works, but we absolutely understand it affects the experience when someone opens an app after it's been idle.
To be transparent: we don't offer an official pre-load / keep-warm capability in the product today. Keeping app data resident in memory indefinitely isn't something we can offer "for free" from a cloud platform perspective — memory is a shared, finite resource across tenants, so we're actively investigating how we could offer this as a proper, monetizable capability going forward. More details will be shared on that as it develops.
In the meantime, there are a couple of things already in motion that should help with the underlying problem:
New CPU core types are being rolled out on the backend for all tenants, at no additional cost. In our testing, this has shown up to a 20% improvement in performance for app opening and other CPU-heavy tasks.
A preview mode is planned for Q3 2026, which will let users see a selectable sheet within seconds, even while the full app is still loading in the background.
So the direction we're heading in should meaningfully reduce the pain point you're describing without needing an external keep-alive service.
One flag for you: the approach you've built (holding idle QIX WebSocket sessions open) works today, but it's not an officially supported pattern, and there's a real chance it could break or become unnecessary once we introduce a proper pre-loading capability. Wanted to raise that now so it doesn't come as a surprise down the line.
If cache warming / app pre-loading is something you'd find valuable as an official feature, it'd be great if you (and anyone else reading this) could submit or upvote an idea on Qlik Ideation — that helps us prioritize it against other roadmap items and gives us something concrete to point to internally.
Appreciate you raising this, and happy to update the thread as we have more to share.
