FYI, I’m running version 18.0.2~ynh1…
I’m running the same version, current master release
So the result of my benchmarks
Install nextcloud, change the fpm config to
pm = dynamic
pm.max_children = 9
pm.start_servers = 4
pm.min_spare_servers = 4
pm.max_spare_servers = 6
Restart php-fpm and reach the main page (with the welcome splash screen).
8.60s to have that wonderful blue square.
Uninstall of nextcloud, reinstallation.
php fpm to
pm = dynamic
pm.max_children = 9
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 4
Restart php-fpm
Stupidly forgot to clear the cache… Never mind…
The page with the welcome splash screen.
12.56s
Clearly a difference.
Now, probably that my processor is faster than the one of a Raspberry pi.
But clearly it makes a difference for me.
It is faster for me too, except for the first page load. I noticed that it happens after login (open Incognito, go to https:///nextcloud/login.php (loads within a second), enter credentials, click login, and wonder at the one server being stuck at 100% again.
So it is something that’s happening within Nextcloud and since you do not seem to able to recreate this issue, it’s most likely I screwed something up…
I did not login, because I wasn’t in private, so I went from my ynh portal.
But actually, even if 8s to load a page is fucking long !!! For nextcloud I’m not really surprised… It’s always slow on my server…
Are consecutive loads/refreshes also that slow? Should be way more responsive after that, it is on my Pi…
Filling opcache and building db connections take time 
I didn’t really try that much, but clearly after the first time it goes smoothly that the first shot.
But, maybe you do have some trouble with the terrible… apcu…
Relying fully on Redis saved me the 2-3 seconds I kind of mentioned between the lines.
I did came across a github comment they fixed something in 18.0.3 but of course no longer can find it (it was in one of the many Incognito sessions :P). I’ll let it sit for now, see if it auto-magic-ally fixes itself in 18.0.3, else I will do a bigger deepdive. Perhaps restoring my deployment in a VM shows some insight vs a fresh install…
You can try the current testing if you want, which is on 18.0.3
I’m considering that too, but first need a backup of the data which is running now and may take a couple of days…
Did you wait for 10 minutes after upgrade?
Maintenance operations (including indexes generation) are set to be run 10 minutes after upgrade.
after ynh upgrade or nextcloud upgrade?
Nextcloud package upgrade.
I have made some progress:
Create a VM, installed stretch, installed the latest Yunohost (curl | bash), configured test domain, added users, installed cert as root on client, shutdown server and created a snapshot.
Next, I booted the server installed Nextcloud 18.0.2, logged in and closed the browser (to get Nextcloud initial stuff happening). Then with Incognito, do a fresh login. Result: Slow login experience taking ~10 seconds (faster cpu), only one child being used (of 5) hitting 180% cpu.
I saved another snapshot.
Then, I booted server, installed Nextcloud 15.0.4 from zip from Dec 29 commit in Master (https://github.com/YunoHost-Apps/nextcloud_ynh/tree/9c57c2f78f3da979d587d708eb9379ffaa41bcfa). Logged in and closed the browser (to get Nextcloud initial stuff happening). Then with Incognito, do a fresh login. Result: 4 seconds, starting with 2 children, quickly expanding to 4, never going over 80% cpu.
So, something changed, either between php7.0 and 7.3, or Nextcloud 15 or 18…
Indeed, considering you get 1 child at 180% first, and 2 children sharing the load, something is clearly happening here.
However, did you check the fpm config in your first install ? how many start children and min_spare?
Because between, 15 and 18, there’s a lot of changes !
The fpm config isn’t the same, the php version neither, and the php packages have changed as well.
No there are 4 children running, only one is active at 180%, the other three stay idle. Differently put: 15 is faster with less children than 18.
18.0.3 shows the same behavior as 18.0.2… If I replace nextcloud_ynh/scripts/upgrade.d/upgrade.last.sh from commit for version 18 with the one from version 15, would that auto-magic-ally install v15 on php7.3-fpm?
Huh no, i don’t have exactly the migration process in mind, but it will probably try to upgrade from 15 to 16, 17, 18 and go back to 15. Which would probably end up with a big mess.
So for you clearly 18 is slower, whatever the php config ?
Only difference to php7.3 config now is:
env[PATH] = $PATH
php_admin_value[memory_limit] = 512M
Removing memory limit doesn’t help.
What would be the best way to get v15 on php7.3-fpm?
No actually you were right, the script uses next_version for the upgrade.
So, if you change next_version and nextcloud_source_sha256 it would probably work.