New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Desktop: Set keep-alive for WebDAV/Nextcloud sync #4668
Conversation
@tessus would you be able to tests this on Mac? I see no reason why it should not work there but can't be 100% sure. |
Yes, I can do that. I'm not sure if I get to it today though. Did you generate X notes per test run? Was the size of each note the same, or only the sum of these X notes? |
I just used a dump of my "production" Joplin database. The stats are:
Total resources size is ~200 Mb. |
Well, that was a bust. I knew that Joplin's sync performance was bad, but I never thought that it was that bad. Abysmal really. My desktop app usually syncs in the background and I sync every 5 minutes, so only a few notes are synced. That's why I've never notived how bad it actually is. The fact that the desktop clients can't do h2 is a very big issue. SetupNextcloud 19, https Server: 100 Mbit round-trip min/avg/max/stddev = 118.747/124.031/128.298/3.064 ms I can download/upload from that server with 10-12 MB. (Although in my apartment I have an upstream cap of 15-20 Mbit.) ResultSize of notes + resources: 15.2 MB (yes, you've read that correctly)
dev (76c143e)
webdav-keepalive (dabfd06)
|
Thanks for testing!
I think there's some room for improvement for WebDAV and others, but that's another conversation. It's quite surprising that this change made things worse on MacOS. |
Also just noticed that there's also a method to check for FreeBSD! Wonder if anyone is using Joplin there. |
That's an understatement. Syncing 15.2 MB in 1.45 - 1.8 hours is not usable. I'm shocked. Really. I am actually speechless. |
Not sure why but this seems much slower than my test on Linux. Took me 1hr to sync 200Mb to a 3rd party (i.e. not on a local network) WebDAV instance with https enabled. |
I have no idea. I can create a test account on my Nextcloud, if necessary or wanted. |
I doubt it's my server though. In the Nextcloud web UI I can upload a 16 MB file in 25s (my upstream bandwidth sucks), but the download is under 2s. |
Definitely not necessary. I'm curious but probably won't have time to check within the next few weeks. |
There's something wrong with either your test, laptop or server @tessus because that's just ridiculous. Of course it doesn't take 90 minutes to sync 15 MB. I have 700MB and it doesn't take 3 days to sync it with Nextcloud, more like 1h. Anyway, I'd be more interested in knowing if it works with mobile. Did you have the opportunity to check @roman-r-m? |
This change is only for desktop, I will take a look at mobile (Android only really) |
I don't see how, @laurent22. I ruled everything out, as you can see from my comments. If I can download a 16MB file via Nextcloud in less than 2s and upload the same file in 25s to Nextcloud, I ruled out network issues for the client and the server. The upload speed is that "bad" because of the the 20Mbit upstream limit from my Internet provider. It does not explain the horrible sync time though. I ran tests from a VM in Azure and AWS and the download and upload maxes out at 12 MB/s for a file transfer. (No server issue.) I also added the ping latency and a speedtest. Btw, I can run the speedtest and a file upload/download while the sync is in progress. No difference. I also offered a test user that you can run these tests yourself. The test looked like this.
Of course I used different paths for the sync target for each test. I've been in DB2 performance for many years, so you can be assured that I do know how to run performance tests. |
Can I get one? Sounds like an interesting challenge to see what's going on there. |
Ok not sure what's going on then. 910 items would not be that fast to upload anyway because, unlike download it's not parallelised, but for example in my recent test it took 24 min for 744 items with Nextcloud - https://discourse.joplinapp.org/t/joplin-server-pre-release-is-now-available/13605 |
Laurent, the mystery is solved. Nextcloud was and is the problem. The WebDAV access and what they do in the background when you access a file via webdav is extremely slow. I just synced the same data as yesterday in 17m 1s (1021 s) via normal WebDAV. This is just mind-boggling. I'm using Apache with event MPM, php-fpm (7.4) + OpCache, MySQL8 (via socket), Redis (via socket) (memcache.locking), APCu (memcache.local). The entire MySQL database fits into memory. All Nextcloud php files are compiled and cached in the OpCache. |
Indeed that's strange. Perhaps the PHP opcache is somehow not working or not properly enabled in the ini file? I've always assumed that the big reason Nextcloud is slow was because WebDAV in general is slow, but it looks like Nextcloud adds some overhead too. |
I think it may be a problem with your Nextcloud or server config. Here #4625 (comment) I synced 200Mb in 30 minutes (with keep-alive) to https://cloud.woelkli.com (so not on my local network). Still slow but not as slow as with your server. |
Nope, it is working and the Nextcloud PHP files are in the cache.
It's possible, but I wouldn't know where. I use all caches available (Redis, APCu, OpCache), everything fits into memory (even the MySQL database), I use sockets to not even have a TCP overhead for local connections, I use self-compiled Apache and php binaries (including their dependencies). I really don't see where I could have screwed up. No matter, I'm moving the sync target to native WebDAV and be done with it. |
Laurent, I can confirm that on Android we set Keep-Alive. |
IMO |
I agree. Just being overly cautious here. I'd much rather have it enabled for all platforms. |
Laurent, was there a reason why |
I guess we could enable keep-alive for all platforms but keeping in mind it would be a bit of a gamble. WebDAV implementations, network stacks and libraries have glitches and any change like this one might trigger them. As an example I've spent several hours on this React Native bug because suddenly their fetch library was requiring the Content-Type header to be set and the only error message was "Network request failed". See also the "JoplinIgnore-" header hack to go around a bug in the iOS network stack.
They should but they don't and that's what we need to work with. So let's try to enable it on all platforms and hopefully if there's a regression in some contexts we'll be able to know it's due to this parameter. |
@roman-r-m, so could you enable it on all platform then please? And you say it was already enabled on Android/iOS? Or is it something that needs to be done? |
This is done.
Enabled on Android - I have verified with tcpdump. However, I do not know enough of iOS to confirm. |
Oh I see, you mean it's already built-in? Not something we need to manually enable? |
Exactly. It's part of OkHttp library |
Ok let's give it a try then, thanks for looking into it Roman. |
This is a follow up to #4625
I ran a test on Windows 8:
~6.5 minutes
~3 minutes
The sync was pretty fast as the server was on the same network and did not have https. As with Linux, I expect the difference to be much higher with https enabled.