GitHub Repo
Open WebUI Community Reports Redis Streaming Write Amplification as Long Replies Repeatedly Save Full Text
A report from the Open WebUI community on October 15 says streaming replies rewrite the accumulated full text to Redis token by token, increasing transfer costs for long-running agent tasks. It includes measurements using a simulated model and reproduction steps, but an official fix release and the impact on real deployments remain unconfirmed.
Open WebUI received a performance report on October 15 concerning its Redis streaming path. The author, Classic298, says the live replica used to resume display after a page refresh rewrites the accumulated reply whenever a token arrives. A separate broadcast path for live viewing also repeatedly sends the full content. As a result, costs rise with the length of a reply and the time it takes to produce. GitHub report
The author measured the current development branch with a single instance, Redis, and a simulated model producing stable output. A 387 KB reply that took 241 seconds generated a cumulative 23.6 GB of writes to Redis and 307 MB of broadcast data. These figures are cumulative transfer volumes under specific test conditions; they should not be read as Redis’s simultaneous memory usage or applied directly to all models and deployments. Measurements and reproduction steps
This path is especially relevant to scaled deployments. The official scaling guide requires multiple instances to share Redis to coordinate WebSockets and application state, so adding application replicas also means assessing load on the shared messaging service. From an engineering perspective, if updates continue to carry the full accumulated text, faster model output or longer-running agent tasks could both increase serialization and network costs. Looking only at inference tokens/s would not reveal the overall bottleneck. Scaling guide
Operators can start by monitoring Redis inbound traffic, slow queries, and Pub/Sub client disconnection counts, then reproduce the issue with long replies and multi-turn tool tasks. The official environment configuration documentation already warns that large streaming events can exceed subscriber buffer limits. Raising the limit can accommodate temporarily slower receivers, but it also permits greater memory usage. Given this mechanism, increasing the buffer size cannot eliminate the cost of repeatedly sending the full text. Follow-up checks should track whether updates switch to incremental data, whether snapshot frequency is reduced, and whether refresh and multi-user viewing remain consistent after a fix. As of the time of review, no official fix release had been confirmed. Environment configuration