Git Annex web app (started from KDE menu) is so slow that it's unusable, after any click, response time is some 30 seconds. It's so slow even on newly-created empty repository. Killing all git-annex processes doesn't help.
Version: 10.20241031-1~ndall+1 OS: KUbuntu 24.04
Just tested more: - Brave - slow - Chrome - slow - Firefox - works like a dream
It seems it's something wrong with Chromium-family browser support. There are no JavaScript and network errors in developer console. I also tried to start git annex webapp with --vebose and --debug flags - nothing there as well.
Tried in chromium, also seeing it block sometimes, though not always, on page loads.
This seems rather similar to this old bug involving the same software: https://github.com/yesodweb/wai/issues/146 But not I think quite the same, because that was caused by a long delay between clicks, and this happens when clicking immediately.
The browser's network console shows a few ms for all resources to load, except the page itself which for some reason takes a log time.
tcpdump shows that chromium does not send a request for that page until many seconds after the click. The response to the request is immediate.
Before that point there is only some SYN/ACK traffic. Which looked a bit weird maybe.
Looking at the network inspector, it seems more likely a given click stalls when there are multiple long polling requests ongoing at the same time (which show as "pending").
So on a hunch, I disabled javascript in chromium. No more hangs.
I suppose maybe chromium has a small pool of connections to the web server, and if all of those get blocked up doing long polling, and if it doesn't cancel those when navigating away from the page that made the long polling request, it could block?
But why wouldn't it cancel them? The requests were made by the page it's navigating away from. Maybe it cancels them only once it's loaded the new page.
I do think that's it though. When I open 2 tabs both to the webapp, a request in one tab can be stalled, and pressing escape in the other tab, when it cancels the long polling requests, will unstall it.
Amazingly, chromium is limited to 6 concurrent connections per server, with no way to configure it! And the front page of the webapp opens several long polling connections.
In firefox, by comparison, the network inspector shows the long polling connections apparently disappear when navigating to a new page. But, there is a similar problem, when opening 2 tabs to the webapp, one can stall, due to the long polling connections open by the other tab.
So, I think the solution to this will either need to involve some change to the long polling javascript, if there is some way to make chromium cancel the request when navigating away... Or it would need to replace the long polling with something else entirely.