Here is the magnet link for the image with redis, hopefully we’ll see a performance improvement
magnet:?xt=urn:btih:f83762a044a86fe76d82cd5428445ed079056336&dn=NextCloudPi%5F10-28-17%5Fbuild-devel&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce
Be aware than the image is for testing only. If the tests go well everyone will receive the update through nc-update
Thanks
Super!
I think I can give it a try today 
Let me update you later on.
E.
Hi
For parallel upload control: set enviroment variable (in the client machine) OWNCLOUD_MAX_PARALLEL to the value you want. If you set it to 1 , only one file transfer, no parallelism.
Hi @guerrero
is that variable in the client source code or can be set externally in the nextcloud.cfg file located in C:\Users<username>\AppData\Local\Nextcloud
?
THanks,
E.
Hi,
sorry for being unclear about filesize.
I didnt sync files >2GB, but I also didn’t want to do the tedious job of manually excluding all files >2GB. Obviously that wasn’t a good idea…
Hi Edson
It’s an enviroment variable. You have to set it in Windows, not in client source code neither in nextcloud.cf. Google “windows set environment variable” to find out how.
Thanks for the input and noted 
I know Win env variables, those are “easy” but google is always kind enough when in doubt I think I will give it a try after testing using the “normal” environ test methodology + the latest dev-test image from @nachoparker
E.
Just FYI, I have 20 GB in nextcloud folder. Using the latest Nextcloud client, I can upload/download all that data to a Mac in about 1 hour.
Ok, that’s interesting
I wonder if the mac client does not use parallel uploads.
hi @nachoparker
While preparing the environment for testing, I was just uploading my last 1.2GB file to NC via webUI and it stopped 
analyzing the NC logs I see the the file is locked… It was just 1 file upload
Anyway, let me get this sorted, back my NC files and then start the test with that image you sent.
E.
Probably because even 1 file it uses 4 streams
Hopefully there will be good news with the redis image!
hi @nachoparker
Seems that after configuring/setting up LetsEncript NC stops working I repeated the steps 3x and I confirm this.
When I try to load the page “locally” at my RPi3 I get:
This page isn’t working
192.168.1.20 is currently unable to handle this request.
HTTP ERROR 500
The strange thing is that https://192.168.1.20:4443/ works well
I burned the image one last time, I will test but skipping the LetsEncript step.
brb
E.
mmm no good! let me try that image again on my pi
Weird, I just reflashed the redis image, extracted fresh from the torrent I gave you and it works dO_Ob
I moved the datadir, and I am now testing uploading many files from the web interface
https://ownyourbits.com/wp-content/uploads/2017/11/redis-test.png
I am also looking at the redis logs
root@nextcloudpi:/media# tail -f /var/log/redis/redis-server.log
642:M 06 Nov 20:49:50.684 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
642:M 06 Nov 20:49:50.684 # Server started, Redis version 3.2.6
642:M 06 Nov 20:49:50.695 * DB loaded from disk: 0.010 seconds
642:M 06 Nov 20:49:50.695 * The server is now ready to accept connections at /var/run/redis/redis.sock
642:M 08 Nov 17:24:54.530 * 1 changes in 900 seconds. Saving...
642:M 08 Nov 17:24:54.531 * Background saving started by pid 1035
1035:C 08 Nov 17:24:54.880 * DB saved on disk
1035:C 08 Nov 17:24:54.883 * RDB: 0 MB of memory used by copy-on-write
642:M 08 Nov 17:24:54.933 * Background saving terminated with success
642:M 08 Nov 17:29:55.078 * 10 changes in 300 seconds. Saving...
642:M 08 Nov 17:29:55.079 * Background saving started by pid 3438
3438:C 08 Nov 17:29:55.335 * DB saved on disk
3438:C 08 Nov 17:29:55.338 * RDB: 0 MB of memory used by copy-on-write
642:M 08 Nov 17:29:55.381 * Background saving terminated with success
Everything looking smooth here :S
edit: testing with 8 GBs of NextCloudPi images (~800MB each)
Bizarre 
and I have repeated the steps 3x, meaning reflashed the mSD 3x…
Yes, very weird
Well, I am testing it now anyway, let’s wait until I finish some testing and if the performance is good for me, we can try a normal image with redis (that works for you) using the windows sync client
Thanks for everything
Testing looking good so far from the web UI. Old USB harddrive
I uploaded 500 wallpapers totalling 250MB with no issue. Upload was slow on average and there was some I/O blocking in the mysqld process. Upload average around 500 KiBps.
Uploading 10 ~800 MB images (so 8GB) was working well at full speed ( 11 MiBps in my home non giga network by ethernet). No issues here.
Also tried with a bigger 1.5 GB image, all fine
I will compare this to the latest image without redis.
At least it seems like there are no regressions. I will test a bit more and this already looks good to include in the next release.
It started to look more stable but I notice that the transfer stopped and the I could not open the UI… when I manage to open it 20-30 seconds later that cron ran a few seconds ago. I also saw a few errors in the logs:
The client tried to resume a 2-3 min later but no go:
Redis log:
I tried with the non redis image, and the test with 500 pictures is indeed worse
Theres constant blocking of the mysqld process and the traffic goes in bursts from 0 to ~100KiBps, with a lousy average. Definitely keeping this setup
As for @Edson_Rodrigues, can you try leaving the database on the SD card and rebooting?
@Edson_Rodrigues reports that there is improvement with the testing image for him as well and the transfers complete with no locking in the logs.
This will go in the next image, and current users will receive it soon via upgrades.
I think we can close this 
