github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-03-11 00:04:08 -05:00
Code Issues 308 Packages Projects Releases 100 Wiki Activity

Performance Issue: Mouse-Over on Chats Floods Application with Requests #5578

New Issue
Closed
opened 2025-11-11 16:25:05 -06:00 by GiteaMirror · 2 comments
GiteaMirror commented 2025-11-11 16:25:05 -06:00
Owner
Copy Link

Originally created by @chr0n1x on GitHub (Jun 18, 2025).

Check Existing Issues

  • I have searched the existing issues and discussions.
  • I am using the latest version of Open WebUI.

Installation Method

Other

Open WebUI Version

v0.6.15

Ollama Version (if applicable)

0.9.1

Operating System

TalosOS v1.10.2

Browser (if applicable)

Chrome 137.0.7151.104 Windows x64

Confirmation

  • I have read and followed all instructions in README.md.
  • I am using the latest version of both Open WebUI and Ollama.
  • I have included the browser console logs.
  • I have included the Docker container logs.
  • I have provided every relevant configuration, setting, and environment variable used in my setup.
  • I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
  • I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
  • Start with the initial platform/version/OS and dependencies used,
  • Specify exact install/launch/configure commands,
  • List URLs visited, user input (incl. example values/emails/passwords if needed),
  • Describe all options and toggles enabled or changed,
  • Include any files or environmental changes,
  • Identify the expected and actual result at each stage,
  • Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

Mousing over chat titles shouldn't cause http triggers in the UI? Unless there's some functionality in the app that I'm unaware of.

Actual Behavior

after creating a few chats, open the network tab in the browser inspect window. running your cursor over the chat titles causes the frontend to FLOOD the backend with requests.

Steps to Reproduce

My Setup

  • k8s cluster. Talos OS 1.10.2. this might not be relevant but mentioning it because...
  • I used the helm chart to install openwebui. here's my values.yaml file
  • note that I'm not using redis or postgres for the db, just whatever the helm chart installs by default

Steps

  • download a few models
    • Im playing with:
      • gemma3:27b-it-qat
      • hf.co/unsloth/DeepSeek-R1-0528-Qwen3-8B-GGUF:Q8_K_XL
      • hf.co/Menlo/Jan-nano-gguf:Q8_0
      • hf.co/unsloth/Qwen3-14B-GGUF:Q8_0
    • all models have custom adv. params (e.g.: temp set to 0.65, top_p to 0.95, etc)
  • make a few chats with a variety of models
  • regenerate a few responses with different models in the same chats
  • upload one or two documents and query the models in different chats

Then open up browser network tools, run the cursor up and down the list of chats you've created.

Logs & Screenshots

Image

logs from the pipelines & openwebui app pods are all eventually 2xx:

2025-06-18 00:31:41.660 | INFO     | uvicorn.protocols.http.httptools_impl:send:476 - 192.168.86.53:0 - "GET /api/v1/chats/684398f9-8bc2-4851-ab18-26c589e401ce HTTP/1.1" 200 - {}
2025-06-18 00:31:41.788 | INFO     | uvicorn.protocols.http.httptools_impl:send:476 - 192.168.86.53:0 - "GET /api/v1/chats/7b1d7de9-2f79-4649-8bb7-f93ad8f2bfa8 HTTP/1.1" 200 - {}
2025-06-18 00:31:43.035 | INFO     | uvicorn.protocols.http.httptools_impl:send:476 - 192.168.86.53:0 - "GET /api/v1/chats/08eabeb6-e609-45f4-8e92-3ff45664f63c HTTP/1.1" 200 - {}
2025-06-18 00:31:43.036 | INFO     | uvicorn.protocols.http.httptools_impl:send:476 - 192.168.86.53:0 - "GET /api/v1/chats/ef254fbc-136f-42de-bcde-29b1e241c0d4 HTTP/1.1" 200 - {}
2025-06-18 00:31:43.673 | INFO     | uvicorn.protocols.http.httptools_impl:send:476 - 192.168.86.53:0 - "GET /api/v1/chats/687aba35-eab2-4b05-8180-28719dd5faf0 HTTP/1.1" 200 - {}
2025-06-18 00:31:46.251 | INFO     | uvicorn.protocols.http.httptools_impl:send:476 - 192.168.86.53:0 - "GET /api/v1/chats/73a5381e-96a5-4725-b579-f0d9002b5ae8 HTTP/1.1" 200 - {}

The problem though is that the application then takes upwards of 20s PER REQUEST in that gif to complete (some go past a minute)

Additional Information

I noticed this while investigating strange amounts of traffic going to my LB.

helm chart version 0.6.20

Originally created by @chr0n1x on GitHub (Jun 18, 2025). ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Other ### Open WebUI Version v0.6.15 ### Ollama Version (if applicable) 0.9.1 ### Operating System TalosOS v1.10.2 ### Browser (if applicable) Chrome 137.0.7151.104 Windows x64 ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior Mousing over chat titles shouldn't cause http triggers in the UI? Unless there's some functionality in the app that I'm unaware of. ### Actual Behavior after creating a few chats, open the network tab in the browser `inspect` window. running your cursor over the chat titles causes the frontend to FLOOD the backend with requests. ### Steps to Reproduce ## My Setup - k8s cluster. Talos OS 1.10.2. this might not be relevant but mentioning it because... - I used the helm chart to install openwebui. [here's my values.yaml file](https://github.com/chr0n1x/rpi-talos/blob/main/k8s/argocd-deploy/ollama/values.yaml) - note that I'm not using redis or postgres for the db, just whatever the helm chart installs by default ## Steps - download a few models - Im playing with: - `gemma3:27b-it-qat` - `hf.co/unsloth/DeepSeek-R1-0528-Qwen3-8B-GGUF:Q8_K_XL` - `hf.co/Menlo/Jan-nano-gguf:Q8_0` - `hf.co/unsloth/Qwen3-14B-GGUF:Q8_0` - all models have custom adv. params (e.g.: `temp` set to `0.65`, `top_p` to `0.95`, etc) - make a few chats with a variety of models - regenerate a few responses with different models in the same chats - upload one or two documents and query the models in different chats Then open up browser network tools, run the cursor up and down the list of chats you've created. ### Logs & Screenshots ![Image](https://github.com/user-attachments/assets/3438c59b-d024-46e7-986f-86af4d27a9f0) logs from the pipelines & openwebui app pods are all _eventually_ 2xx: ``` 2025-06-18 00:31:41.660 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 192.168.86.53:0 - "GET /api/v1/chats/684398f9-8bc2-4851-ab18-26c589e401ce HTTP/1.1" 200 - {} 2025-06-18 00:31:41.788 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 192.168.86.53:0 - "GET /api/v1/chats/7b1d7de9-2f79-4649-8bb7-f93ad8f2bfa8 HTTP/1.1" 200 - {} 2025-06-18 00:31:43.035 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 192.168.86.53:0 - "GET /api/v1/chats/08eabeb6-e609-45f4-8e92-3ff45664f63c HTTP/1.1" 200 - {} 2025-06-18 00:31:43.036 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 192.168.86.53:0 - "GET /api/v1/chats/ef254fbc-136f-42de-bcde-29b1e241c0d4 HTTP/1.1" 200 - {} 2025-06-18 00:31:43.673 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 192.168.86.53:0 - "GET /api/v1/chats/687aba35-eab2-4b05-8180-28719dd5faf0 HTTP/1.1" 200 - {} 2025-06-18 00:31:46.251 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 192.168.86.53:0 - "GET /api/v1/chats/73a5381e-96a5-4725-b579-f0d9002b5ae8 HTTP/1.1" 200 - {} ``` The problem though is that the application then takes upwards of 20s PER REQUEST in that gif to complete (some go past a minute) ### Additional Information I noticed this while investigating strange amounts of traffic going to my LB. helm chart version 0.6.20
GiteaMirror added the bug label 2025-11-11 16:25:05 -06:00
GiteaMirror commented 2025-11-11 16:25:06 -06:00
Author
Owner
Copy Link

@tjbck commented on GitHub (Jun 18, 2025):

Intended behaviour.

@tjbck commented on GitHub (Jun 18, 2025): Intended behaviour.
GiteaMirror commented 2025-11-11 16:25:06 -06:00
Author
Owner
Copy Link

@chr0n1x commented on GitHub (Jun 19, 2025):

@tjbck are there any docs or explanation as to why? I find this behavior very strange.

@chr0n1x commented on GitHub (Jun 19, 2025): @tjbck are there any docs or explanation as to why? I find this behavior very strange.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#5578
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?