UI is not updating nor saving settings

Hello,

i just started this device, which did not run for a while.
Now i want to change some settings, since there have been changes in the network setup (like add a Device, remove folder shares, add a folder, etc.)

But the UI seems to not get any responses from the backend anymore.

I added the new device 5 times and removed a folder share 8 times and added a new folder 2 times, it always “seems to work” (the ui shows the desired result), but then eventually reverts to the old state (i suppose once a real update from the server arrives).

I have 36 folder, of which some are very large and/or have many files and 9 devices.

[i removed some sensitive parts in the screenshot]

The “config” request in the list on the right was me pressing save on a folder.

None of these requests get any replies. Maybe the backend is stuck or blocked on something or simply overwhelmed with other things to do.

Can i somehow help to analyze this condition further?

Greetings Fred;

p.s. after reloading the page it seems to work fine for a while.

The ui was running fine now so i tried to add the new folder once again:

grafik

The config POST does not get a reply. Maybe it’s not supposed to? But well i guess it should at least send an OK.

I noticed something else.

It might be related to this: I switched to another tab in the browser.

When i returned to the Syncthing tab i got this:

Maybe the browser suspends or throttles the website when it is not active. Now many requests queue up and once the tab is reactivated all these requests are sent.

Then again: What is this completion-request?

It seems to request the same device-ids over and over again.

The responses come in only slowly one by one.

Ideas for a solution:

Maybe these requests should be streamlined for example by allowing only 5 or 10 simultaneous requests to the backend?! This way the backend does not get overwhelmed by these requests.

Then another thing: When the requests are beeing queued they should collapse similar or duplicate requests so the backend has a chance to keep up with the requests and the number of requests is simply reduced by the client, when the server replies slowly instead of firing more and more requests, while the server is already 500% overloaded…

Another attack point could be to optimize the server-side handling of the most frequent requests, eg. by using better caches or in-memory state to reply to them. This way the server can (hopefully) always keep up with the requests fired at it.

One more:

See the footer line: 1959 requests in 7 minutes. 10MB transferred. These events?since= requests seem to be fired several per second (at this point). Maybe there is a bug in the client which causes them to be sent too often. I guess once per second or every few seconds would be sufficient.

Update:

grafik

Now after 12 minutes it got stuck again. It might be triggered by me changing a share setting on antoher device, which shortly disconnects the devices (as far as i know), which probably triggers the restart of some internal processes, which then again probably causes the UI to request a lot of additonal things (i see this completion-request a lot when it gets stuck).

Are you running on some slow device or are you running with any sort of proxy in place?

no, no

Windows 7 Professional
grafik

You should enable config logging and post the logs.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.