Excessive Rendering Lag Makes WebUI Unusable With Default Settings

tayl commented 2 days ago

qBittorrent & operating system versions

Firefox 131.0.3 (64-bit)

What is the problem?

Moving this by request @glassez: https://github.com/qbittorrent/qBittorrent/issues/21595#issuecomment-2424482111

Just to add another data point, I'm experiencing extreme lag in the web UI with default theme running on Linux. It may be totally unrelated, but maybe not - the root cause may be the same. With 500 or so torrents, each call to /api/v2/sync/maindata is returning about 1 million characters, or about the same number of bytes / 1MB. Compressed that's about 132kB over the line. This payload is returned regardless of what the UI is showing - i.e. if I'm filtered to one torrent, I still get the entire payload. Maybe that's a reasonable design choice, I don't know the underlying system well enough to say. But I don't think that's the primary issue.

When all my torrents are showing, each time this data is parsed, there's a period of about 1 second that the UI takes to "redraw" the 1MB payload (notably, UI is blocked during this time). 90% of this time is spent in dynamicTable.js#updateRow. When I filter down to a single torrent, the time taken to "redraw" is unnoticeable. Confirmed that prior to 5.0.0, this issue did not exist.

A refresh rate of 1 second in advanced settings makes the web UI basically unusable. I have it set to 5 seconds now and it's okay but not a real fix.

Firefox 131.0.3 (64-bit)

Steps to reproduce

No response

Additional context

No response

Log(s) & preferences file(s)

Default settings

glassez commented 1 day ago

With 500 or so torrents, each call to /api/v2/sync/maindata is returning about 1 million characters, or about the same number of bytes / 1MB.

Could you provide some of adjacent payloads for review? Note that /api/v2/sync/maindata is supposed to transfer entire data only once and then only changes. So if this is not the case, then perhaps some kind of error has crept into the algorithm.

tayl commented 1 day ago

I'd rather not post the entire payloads, but I ran a diff and can tell you what's changing. alltime_dl, alltime_ul, average_time_queue, total_peer_connections, up_info_data, up_info_speed, popularity, reannounce, seeding_time, time_active.

Obviously timers like seeding_time and time_active will change every time. Most of the others ones are as well, but not for every torrent. Only the timers change for every torrent (expected). The entire torrent object is sent back though, not just the updated timers.

glassez commented 1 day ago

The entire torrent object is sent back though, not just the updated timers.

As I said above it is not supposed to be. Only changes should be sent after first time full data was sent. But looking at the screenshot provided, I see the problem that you have an immutable rid parameter in all requests which isn't supposed to be in normal scenario. Because of this, the qBittorrent sends complete data every time, assuming that you did not receive the previous response. Do you use the built-in WebUI? What are your WebUI settings?

tayl commented 18 hours ago

The entire torrent object is sent back though, not just the updated timers.

As I said above it is not supposed to be. Only changes should be sent after first time full data was sent. But looking at the screenshot provided, I see the problem that you have an immutable rid parameter in all requests which isn't supposed to be in normal scenario. Because of this, the qBittorrent sends complete data every time, assuming that you did not receive the previous response. Do you use the built-in WebUI? What are your WebUI settings?

Using built-in webUI, yes. I have HTTPS enabled. Bypass auth for whitelisted IPs. CSRF enabled. Everything else is default.

glassez commented 17 hours ago

What value has rid in all these adjacent qBittorrent responses?

tayl commented 16 hours ago

rid=1. What may cause it to not increment? I spun up a new instance and see it incrementing as expected. So it is not an image issue, but something with state I guess. New instance has no torrents. I will play around and see if I can figure out what causes it.

tayl commented 7 hours ago

Clearing cache resolved the counter not incrementing, at least temporarily. Still trying to narrow down what causes it. What lives in cache that isn't in config? I'm suspecting columns, will play with them when I have time.

glassez commented 7 hours ago

@qbittorrent/web developers, @skomerko, @HanabishiRecca This is clearly a problem on the WebUI side. Do you have any ideas?

HanabishiRecca commented 3 hours ago

I don't see that issue.

Clearing the cache purges leftovers from previous client versions. Maybe there were some old scripts messing with the code. Basically the same problem as with styles. https://github.com/qbittorrent/qBittorrent/issues/21504#issuecomment-2394176130

qbittorrent / qBittorrent