Slow webinterface, dav works fine (Nextcloud with php-fpm, OPCache, Redis and APCu)

ℹ️ Support
,
1

Nextcloud version (eg, 18.0.2): 20.0.4.0
Operating system and version (eg, Ubuntu 20.04): debian stable
Apache or nginx version (eg, Apache 2.4.25): nginx/1.14.2
PHP version (eg, 7.1): 7.4.10 php-fpm

The issue you are facing:
The webinterface is really slow (20 000ms+ loading time) while the dav etc are fine
(https://check-host.net/check-http?host=https://cloud.torbenarne.de/index.php/login)
Is this the first time you’ve seen this error? (Y/N): No

Steps to replicate it:

  1. Install nextcloud with redis, apcu and OPCache
  2. use it for a while

The output of your Nextcloud log in Admin > Logging:

There is no error per se, so nothing to paste here

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

<?php
$CONFIG = array (
  'instanceid' => 'REMOVED',
  'passwordsalt' => 'REMOVED',
  'secret' => 'REMOVED',
  'trusted_domains' => 
  array (
    0 => 'REMOVED',
    1 => 'cloud.torbenarne.de',
  ),
  'datadirectory' => '/srv/www/nextcloud-data',
  'dbtype' => 'mysql',
  'version' => '20.0.4.0',
  'overwrite.cli.url' => 'https://cloud.torbenarne.de',
  'dbname' => 'nextcloud',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'nextclouduser',
  'dbpassword' => 'REMOVED',
  'installed' => true,
  'mail_smtpmode' => 'smtp',
  'mail_smtpsecure' => 'ssl',
  'mail_sendmailmode' => 'smtp',
  'mail_from_address' => 'REMOVED',
  'mail_domain' => 'REMOVED',
  'mail_smtphost' => 'REMOVED',
  'mail_smtpauth' => 1,
  'mail_smtpname' => 'REMOVED',
  'mail_smtppassword' => 'REMOVED',
  'mail_smtpport' => '465',
  'mail_smtpauthtype' => 'LOGIN',
  'maintenance' => false,
  'theme' => '',
  'loglevel' => 2,
  'updater.release.channel' => 'stable',
  'log_query' => false,
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'memcache.distributed' => '\\OC\\Memcache\\Redis',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'redis' => 
  array (
    'host' => '/var/run/redis/redis.sock',
    'port' => 0,
    'dbindex' => 0,
  ),
  'ldapIgnoreNamingRules' => false,
  'ldapProviderFactory' => 'OCA\\User_LDAP\\LDAPProviderFactory',
  'updater.secret' => 'REMOVED',
  'encryption.legacy_format_support' => true,
  'encryption.key_storage_migrated' => false,
);

The output of your Apache/nginx/system log in /var/log/____:

Nothing in the nginx errorlog or the php-fpm log

Question: Is there a tool through which I could get deeper insights why my nextcloud is slow?

2

Your ipv6 connection is not working, so everyone with an ipv6 version will have to wait for the fallback to ipv4. But you also have a problem with your ipv4 connection, if you open your URL with curl -v https://....
there is a long delay before you get a 200 status response from the server. Certificate and everything seems to pass correctly, so it must be something else. Not sure about your configuration, perhaps some checks or verifications that take so long?

I’d try to increase the log level of your nginx to get more information. I think of things like, do you resolve hostnames in the logs… The 20s you wait for is perhaps some delay for something nginx is waiting for…

3

Thanks for the IPv6 hint. I had this problem before where i forgot the ssl in:
listen [::]:443 http2;
now its:
listen [::]:443 ssl http2;

4

Another thing i found out (not sure if thats the problem) there are a couple of standart things that nginx tries:

2020/12/28 22:02:20 [debug] 1923686#1923686: *51 test location: "api/v1/doh"
2020/12/28 22:02:20 [debug] 1923686#1923686: *51 test location: "api/v1/cgi"
2020/12/28 22:02:20 [debug] 1923686#1923686: *51 test location: ~ "\.php$"
2020/12/28 22:02:20 [debug] 1923686#1923686: *51 test location: ~ "/\."
2020/12/28 22:02:20 [debug] 1923686#1923686: *51 using configuration "/"

not sure if that has something to do with it

5

ipv6 is still not working for me, with -6 you can force curl to use ipv6.

6

yep, thats a bug on my side (my homerouter bugs with ipv6 portforwarding/firewalling), that however doesnt explain the 20 seconds in ipv4

7

im still testing but maybe ipv6 was the problem after all