GitHub Repo
Open WebUI Community Reports Redis Streaming Write Amplification as Long Replies Repeatedly Store 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. The report includes measurements using a simulated model and reproduction steps, but an official fix and the impact on production deployments remain unconfirmed.
On October 15, a performance report about Open WebUI’s Redis streaming path appeared. 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. This means the cost of long replies grows with their length and duration. 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 resulted in 23.6 GB of cumulative writes to Redis and generated another 307 MB of broadcast data. These figures are cumulative transfer volumes under specific test conditions. They should not be interpreted 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 requires assessing the load on the shared messaging service. From an engineering perspective, if updates continue to carry the accumulated full text, faster model output or longer-running agent executions could both increase serialization and network costs. Looking only at inference tokens per second would not reveal the overall bottleneck. Scaling guide
Operators can start by monitoring Redis input 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 warns that large streaming events can exceed subscriber buffer limits. Raising the limit can accommodate temporarily slower receivers, but also permits greater memory use. Given this mechanism, increasing the buffer limit cannot eliminate the cost of repeatedly transmitting the full text. Follow-up should track whether updates switch to sending deltas, 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 version had been confirmed. Environment configuration documentation