Chrome says "Syncing..." and never finishes (local 1Gb connection to idle Server with 6GB RAM and 2x 3.0 GHz cores allocated):
debug.log
Starting sync process for account my_user@https://my_server.net
Overriding title of built-in node 1 Bookmarks bar => Bookmarks Bar
Overriding title of built-in node 2 Other bookmarks => Other Bookmarks
Fetching bookmarks
Floccus 3.0.10
Nextcloud 13.0.7snap1
Bookmarks 0.12.2
Are you able to login via the nextcloud web interface (with no delay)?
@marcelklehr Yes, login via web interface is working properly.
I have a similar problem. I've been testing on Chrome before I roll it out to both, and it's basically ALWAYS syncing. Granted, I have like 8000 bookmarks in 650+ folders (yes, it's a lot, most of them are more reference material than things I actively use). But even when syncing, it just spins. I've never gotten a complete sync from either XBEL or Nextcloud.
I'm using nextcloud as the backend for both.
Conversely, with syncmarkx, it finishes syncing in like 5 seconds.
Is it floccus or the nextcloud bookmarks app that does a HTTP request for every URL as part of the sync?
Disabling this, which is presumably done for fetching an image of each bookmark, may help with the speed.
Having a large amount of bookmarks to sync is of course one factor that could cause performance problems.
@skewty How many bookmarks do you have?
@den0x This shouldn't be a problem with XBEL syncing, though, as this method doesn't trigger loading of previews.
@TeutonJon78 Any luck trying to figure out what floccus is doing during that time?
ie. with the following:
about:debuggingdebug button next to floccus entrysync now for the account of your choicechrome://extensionsDeveloper modedist/html/background.html button in floccus' entry next to "Inspect views: "sync now for the account of your choiceI am going to guess at around 1000. I can't check now as I took a month off work and away from software development and didn't bring any computers with me.
Scott
Sent from ProtonMail mobile
-------- Original Message --------
On Nov 21, 2018, 5:21 AM, Marcel Klehr wrote:
Having a large amount of bookmarks to sync is of course one factor that could cause performance problems.
@skewty How many bookmarks do you have?
@den0x This shouldn't be a problem with XBEL syncing, though, as this method doesn't trigger loading of previews.
@TeutonJon78 Any luck trying to figure out what floccus is doing during that time?
ie. with the following:
Firefox
- Go to about:debugging
- enable debugging
- click on debug button next to floccus entry
- trigger a sync by clicking on sync now for the account of your choice
- go back to the inspector window and observe
Chrome
- Go to chrome://extensions
- enable Developer mode
- click on dist/html/background.html button in floccus' entry next to "Inspect views: "
- trigger a sync by clicking on sync now for the account of your choice
- go back to the inspector window and observe
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
Assuming this problem is due to performance and not something like a semantic error. There is a lot of room for performance improvement in the code. With this
change as a first step performance should increase substantially as floccus processes up to 10 bookmarks concurrently and can also make server changes for up to ten bookmarks in parallel. There is a slight risk of errors happening due to concurrent execution, but the only way to find those errors is through extensive testing.
Initial syncing usually takes longer than subsequent sync runs, because all bookmarks need to be created. Still, an initial sync of a 1000 bookmarks shouldn't take longer than 1000 / 10 * 20s = 33min, which is already better than 1000 * 20s = 5h 33min.
The second parameter to adjust is the 20s, which is a server-side issue. Indeed the server fetches every URL that is added once to check for redirects, and populate title and description in case they are missing. This could be avoided if the title is already provided, for example, even if the description would be missing in that case. I'll see about that soon.
Another possibility that I just discovered would be that, if floccus fails with a 504 Error from the server, the problem is indeed the server-side request of the newly submitted URLs. Can you confirm the 504 Error?
I've just released v3.1.7 with the aforementioned performance improvement plus some cut downs on the number of performed HTTP requests. Feedback is appreciated.
What is the speed difference for using XBEL vs. the Bookmarks app. 33 minutes for 1000 bookmarks still seems incredibly high for the use case.
@TeutonJon78 Using the XBEL/WebDAV method avoids using all kinds of HTTP requests necessitated by the bookmarks app's HTTP API. It has a constant number of 4 HTTP requests, iirc. So, XBEL is the best choice for avoiding the network as a bottleneck.
EDIT: Also, note that the 33minutes is for an initial sync, aka everything has to be created. Comparing the trees later with only minor differences, should* be much faster.
(* It currently isn't much faster really, only about 2x as fast, because of a variety of issues. Performance is my next goal on the roadmap, though.)
So, with some modifications in the bookmarks app and floccus itself, I've turned it down to ~20min for an initial (cold) sync of 3000 bookmarks with the nextcloud-folders adapter and ~4min for a warm sync with no changes, while the webdav adapter takes ~3min for an initial cold sync, and ~2min for a warm sync. So, as expected the webdav adapter is significantly faster.
So, with some modifications in the bookmarks app and floccus itself, I've turned it down to ~20min for an initial (cold) sync of 3000 bookmarks with the nextcloud-folders adapter and ~4min for a warm sync with no changes, while the webdav adapter takes ~3min for an initial cold sync, and ~2min for a warm sync. So, as expected the webdav adapter is significantly faster.
| adapter | cold sync (3000 Bookmarks) | warm sync (3000 Bookmarks) |
|---|---|---|
|nextcloud-folders|~20min|~4min|
|webdav|~3min|~2min|
These improvements are now available with floccus v3.2.0 by enabling parallel syncing in the options. Ideally, you should also update the bookmarks app.
Any update on this?
I have this same problem. I'm syncing to XBEL via WebDAV with NextCloud. Now, I have no less than 40,000 bookmarks - a big job for sure. However, it will spin for four or FIVE HOURS easily and never ever finish. It consistently leaves the .lock file in place and complains about it on each sync. This is probably because it never really finishes. I left it on all night last night doing a sync. It uses a massive amount of CPU time doing it, used up all my memory (16GB) and just about froze the system (memory leak?), and generally does not perform as advertised. Still, great concept and I'm looking forward to updates and bug fixes. I just need a simple bullet-proof solution that works with my NextCloud. One thing that might be nice is a progress bar on the sync to see where it is in the process.
One thing that might be nice is a progress bar on the sync to see where it is in the process.
This has been suggested before, I realize. I think it's a good idea to overcome the feeling of sync being 'stuck'. I've just implemented it :)
The plugin is staying with the "Syncing..." status whenever an error is encountered instead of displaying "Error". For example, add a non existing nexcloud account (like the default with [email protected]). Then you cannot do anything because there is an error, obviously the server is not reachable, but the plugin is stuck with the "Syncing..." status. You cannot disable the account, cannot delete it, cannot modify it.
I have the same exact problem with a sync error with a non existing item. Now the plugin is stuck with the "Syncing..." message and I cannot stop it, nor disable the account, nor do anything. Only solution is to close the browser or disable the plugin then enable it back.
Improvement idea: better handling of errors. If error => get out of "syncing" status.
I have the same issue - getting stuck in sync status forever while all bookmarks (don't have that much, maybe 200) are already synced - but only on Chrome. On Firefox the sync finishes within a few seconds (even cold sync is very fast - the progressbar is "racing" while in Chrome I can only tell the diffrence of progress after hours). You mentioned webdav is much faster - should we be using webdav instead of the nextcloud adapter? has it any downsides?
Improvement idea: better handling of errors. If error => get out of "syncing" status.
yes, sorry, that was a bug. It should be fixed, now.
You mentioned webdav is much faster - should we be using webdav instead of the nextcloud adapter? has it any downsides?
The only downside of webdav is that you won't be able to use the nextcloud bookmarks UI. Other than that, by all means try it! :)
The only downside of webdav is that you won't be able to use the nextcloud bookmarks UI. Other than that, by all means try it! :)
ah okay, I'll stay on the nextcloud-version in this case sicne I didn't find a decent way to use XBEL-files on Android. BUT: I've just set up my account from scratch and ticked the parallel-sync box which improves sync speed on chrome A LOT! Will have to check if this stays the same when I set up all other browsers/machines as well but currently this looks very promising - thanks again for this great extension! :)
I've just set up my account from scratch and ticked the parallel-sync box which improves sync speed on chrome A LOT! :)
Update: while working fine 2 days ago yesterday my server (4 cores, 6gb ram) got crushed by the the workload produced by floccus with parallel sync on (about 44.000 requests in 4h) and I had to disable it to bring the server back online :(
Update 2: after switching to webdav everything is working smooth and fine - now I just don't know to get them to Android. Do you have any suggestions?
while working fine 2 days ago yesterday my server (4 cores, 6gb ram) got crushed by the the workload produced by floccus
I recently got an idea on how to further reduce the workload on cold-cache syncs, which will hopefully mitigate this kind of issue.
Do you have any suggestions?
I sadly don't know of any xbel viewer apps.
thanks, but I think I'll stay on the webdav-version - working so great and with fewer requests, that's really awesome! will think about some solution for android...
Just a quick update if anyone else is interessted in a solution for Android: the latest version of Kiwi-Browser supports Chrome extensions - not all are working but floccus is :D
I have the same problem and a high server load (0,9-1.1). After i deactivated floccus 3.2.15 on my firefox 66.03 (bookmarks 0.17.0 on nextcloud 15.07), everything okay:

A tangential problem is probably, that the sync interval of 15min causes it to sync continuously when the sync takes longer than that. I guess, a sync interval option is in order after all, to mediate this. :/
@omocinteractive in v3.2.16 I fixed a bug that would cause it to sync continuously.
Great - thx a lot! It seems to work now!
... hm. It's a high performance dedicated server with 64gb ram - strange to the see the load only for synchronizing bookmarks. The Server is only a Mirror-System for a online application, therefore normally nothing is usually going on. It would be nice to synchronize only one time i start firefox.

It would be nice to synchronize only one time i start firefox.
Because of the low performance?
strange to the see the load only for synchronizing bookmarks
Do you sync your files as well? I suppose part of the load stems from the fact that floccus currently downloads all your bookmarks to reassemble the tree and compare the hashes per folder. An improvement would be to hash the folders on the server and only send the hash.
Feel free to try out the v3.3.0 beta (see #269) to see this implemented :)
What are your experiences with v3.3.x so far?
What are your experiences with v3.3.x so far?
Webdav is sooth and fast as ever :)
Thanks again for this awesome extension - together with Kiwi Browser for android it's the perfect solution for me new!
This version is much faster than previous versions. It is finally a viable option. I still get occasional lock file leftover and need to manually delete it. Some racing conditions?
Other than that I have no complains. Thank you for this extension
A head up that I'm using 3.3.2 on Firefox and Chrome on Linux Mint at the moment and for some while now it seems it's stopped working, simply stuck synching forever. :-(.
I can look at debug logs, but admit my first thought reading them is "wow they sure could use a timestamp before each line" as it's not clear what the age of the log is. But the last line on FF is:
Syncing failed with E017: Network error: Check your network connection and your account details
And on my Chrome is:
Successfully ended sync process for account myaccount@myserver.
Now my server is working fine. I use it daily. It's a NextCloud Pi server on a home fibre connection which is assymetric link 50 Mbps down and 20Mbps down evidenced here:
https://www.speedtest.net/result/8359781466
And I have a speed tester running on a server inside my LAN here:
http://speedtest.thumbs.place/
It's not the zippiest cloud server on a Pi behind 20Mbps up but it's always worked fine and woks fine. But something with Floccus has changed and is hanging.
@bernd-wechner Thanks for the feedback. Can you open a new issue for this, please? :) To investigate further, try the live log:
go back to the inspector window and observe
Go to chrome://extensions
v3.4.0 (currently in beta: #338 ) leverages a new endpoint of the bookmarks app, which dramatically reduces sync duration with nextcloud:
adapter | cold initial sync (4000 Bookmarks) | warm sync with no changes (4000 Bookmarks)
-- | -- | --
nextcloud-folders | ~7min | ~20s
webdav | ~4min | ~10s
This is the latest in a series of improvements that have reduced initial sync time from initially multipe hours to half an hour to now 7 minutes.
@marcelklehr awesome, thanks for all your hard work on this! Have been using the webdav-version for some while now and can't imagine any other option to sync bookmarks anymore :)
@bernd-wechner Thanks for the feedback. Can you open a new issue for this, please? :) To investigate further, try the live log:
Firefox
* Go to about:debugging * enable debugging * click on debug button next to floccus entry * trigger a sync by clicking on sync now for the account of your choice * go back to the inspector window and observeChrome
* Go to chrome://extensions * enable Developer mode * click on dist/html/background.html button in floccus' entry next to "Inspect views: " * trigger a sync by clicking on sync now for the account of your choice * go back to the inspector window and observe
Sincere apologies for dropping the ball on this. Just found it again closing tabs. But to be onest it's been working finish for a while. I get intermittent timeouts and they almost certainly relate to sluggish performance of my nextcloud sever (which is running on a Raspberry Pi and is on a domestic 50/20Mbps link). So all I'd say it might be nice if we could increase the timeout manually.
So all I'd say it might be nice if we could increase the timeout manually.
Currently, the timeout is 1 minute. Do you really need more than that? :thinking:
Hard to say from my perspective. Would surprise me if so, but can't hurt to allow it. Essentially the problem some might face (and I do) is that they are running NextCloudPi so on a Raspberry Pi, which is not exactly a performance demon ;-), and it wouldn't take much to go wrong in one with regard to memory consumption or leaks to bring it down to real slow rates, that a reboot might might fix.
On top of that it sites behind a domestic interrnet link which in Australia at least implies heavy asymmetry in speed, nominally I'm on a 50/20 Mbps link meaning 50Mpbs incoming and 20Mbps outgoing. Still, 20Mbps should be more than enough to satisfy a bookmark transfer within a minute, plenty more than enough, so if things got real slow it would be suggesting either congestion on the provider side that sees service level drop, or congestion on my side (as in I also run a few other things like a website or two on the same link ;-). though it's hard to imagine anything I do congesting 20Mpbs. It's easy to forget just how blazingly fast modern links are (given I grew up on 300bps links ;-) and we were running websites on 256 and 512 bps and the 1 Mbps links happily for some time.
Perhaps more important than a longer timeout (though the flexibility to exeperiment with one is never amiss) is if the floccus fails on a timeout there's a clear indication either on screen or in the debug log as to what it was waiting on. Like had it got any response out of the remote server yet, a successful handshake, login, etc and is timing out on some later step or is it timing out on the initial contact effort.
The reason being these are very different scenarios to diagnose. One is connectivity full stop and the other is the response time of the bookmarks app on Nextcloud for expampel.
Anyhow, juts my idle thoughts. Mine seems to have finally synched again after weeks of hanging, and I'm really not sure what changed (or better said what change helped that along). The main change is that I upgraded my NexcloudPi server the whole schemozzle, every little bit of it that wanted an upgrade or told me it had one available, so that's at the Respbian level, the NextCLoudPI level and the Nextcloud level and the Nextcloud Apps level ... so it's all totally satisfied happy chappy up to date on everything.
I'm not sure if anything else changed.
What was bugging me is that even the Cancel button on Floccus was not responding, and so browser restarts were involved as well, and there might have been a browser upgrade or two involved in that (as on the Linux side at least upgrades are so stunningly unintrusive and elegant it's not funny, as in you just OK the upgrades notified but nothing ever, wants to be, asks to be, let along insists to be restarted - which Windoze always forces upon me! - and the update happens silently and without notice on next restart of the box, or app as relevant, so a restart of browsers on a Linxu box might well see updates applied).
So given all those updates it's really hard to know what might have loosened things up again and seen successful synching! I will see at work tomorrow if my WIndoze browsers likewise respond with success.
I'm closing this for now. If you have a problem along the lines of this issue, feel free to open a new one.
Most helpful comment
Just a quick update if anyone else is interessted in a solution for Android: the latest version of Kiwi-Browser supports Chrome extensions - not all are working but floccus is :D