30s+ to login and load

I have searched the archive and found related topics, but none of the solutions have been able to help me.

Nextcloud version (eg, 20.0.5): 27.1.4
Operating system and version (eg, Ubuntu 20.04): Ubuntu 22.04
Apache or nginx version (eg, Apache 2.4.25): Apache 2.4.41
PHP version (eg, 7.4): php8.1-fpm

Displaying the logon dialogue or reloading the files menu takes much too long: about 30 seconds. Developer tools in Firefox show that it is taking that long to load javascript libraries: Imgur: The magic of the Internet

I tried the following to improve the load time:

  • Apache: using mpm_event instead of mpm_prefork
  • Tuning php-fpm with recommended values
  • Verifying that redis works and is being used by Nextcloud (redis cli; MONITOR)
  • Checked Nextcloud logs: nothing special
  • Checked Journald logs: nothing special
  • Checked MariaDB logs: nothing
  • Tested with a different browser: same load times
  • MariaDB: activated slow-log. Analysis with mysqldumpslow: no operation longer than 0.08sec
  • Apache: activated compression for css, Javascript, svg+xml
  • Apache: activated http2

Now I don’t know how to proceed. Do you have an idea? Thank you for any hints.

35 MB Javascript. Unbelievable for a small web application. For me it’s more like only 10 MB but also far too much. Sort by the size of the Javascript files and post the list.

you mean like this?

root@myhost:/var/www/nextcloud# find . -name '*.js' -exec du -h {} + | sort -hr | head
15M     ./dist/core-common.js
7,7M    ./apps/text/js/vendors.js
5,7M    ./apps/calendar/js/calendar-main.js
5,1M    ./apps/text/js/text-viewer.js
4,2M    ./apps/notes/js/notes-main.js
4,2M    ./apps/calendar/js/calendar-vendors-node_modules_nextcloud_cdav-library_dist_dist_js-node_modules_nextcloud_moment_dist_i-f6d773.js
4,1M    ./apps/photos/js/photos-public.js
4,1M    ./apps/photos/js/photos-main.js
4,0M    ./apps/polls/js/polls-dashboard.js
3,8M    ./apps/polls/js/polls-main.js
  • Admin warnings under Admin->Overview?
  • Are you using a reverse proxy or anything like Cloudflare?
  • Any non-default Apache modules (i.e. ones you installed yourself)?
  • You need to provide the output of occ config:list system (or equivalent)
  • Please post the output of occ app:list
  • When did this behavior start?
  • Admin warnings under Admin->Overview: None (all ok)
  • Reverse proxy: No
  • Non-default Apache modules: Not sure what you mean with non-default, but here are all:
$ sudo apache2ctl -M
Loaded Modules:
 core_module (static)
 so_module (static)
 watchdog_module (static)
 http_module (static)
 log_config_module (static)
 logio_module (static)
 version_module (static)
 unixd_module (static)
 access_compat_module (shared)
 alias_module (shared)
 auth_basic_module (shared)
 authn_core_module (shared)
 authn_file_module (shared)
 authz_core_module (shared)
 authz_host_module (shared)
 authz_user_module (shared)
 autoindex_module (shared)
 bw_module (shared)
 deflate_module (shared)
 dir_module (shared)
 env_module (shared)
 filter_module (shared)
 headers_module (shared)
 mime_module (shared)
 mpm_event_module (shared)
 negotiation_module (shared)
 proxy_module (shared)
 proxy_fcgi_module (shared)
 proxy_http_module (shared)
 proxy_wstunnel_module (shared)
 reqtimeout_module (shared)
 rewrite_module (shared)
 setenvif_module (shared)
 socache_shmcb_module (shared)
 ssl_module (shared)
 status_module (shared)
  • output of occ config:list system:
{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "myhost.mydomain.mytld"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "overwrite.cli.url": "http:\/\/myhost.mydomain.mytld",
        "overwriteprotocol": "https",
        "dbtype": "mysql",
        "version": "27.1.4.1",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "ldapIgnoreNamingRules": false,
        "theme": "",
        "maintenance": false,
        "secret": "***REMOVED SENSITIVE VALUE***",
        "loglevel": 2,
        "trashbin_retention_obligation": "auto",
        "updatechecker": false,
        "htaccess.RewriteBase": "\/",
        "logfile": "\/srv\/data\/nextcloud.log",
        "log_rotate_size": 104857600,
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.local": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 6379
        },
        "ldapProviderFactory": "\\OCA\\User_LDAP\\LDAPProviderFactory",
        "mail_smtpmode": "smtp",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mysql.utf8mb4": true,
        "onlyoffice": {
            "verify_peer_off": true
        },
        "auth.webauthn.enabled": false,
        "default_phone_region": "DE",
        "defaultapp": "files,dashboard",
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***"
    }
}
  • output of occ app:list:
$ occ app:list
Enabled:
  - activity: 2.19.0
  - admin_audit: 1.17.0
  - bruteforcesettings: 2.7.0
  - calendar: 4.5.3
  - circles: 27.0.1
  - cloud_federation_api: 1.10.0
  - comments: 1.17.0
  - contactsinteraction: 1.8.0
  - dashboard: 7.7.0
  - dav: 1.27.0
  - federatedfilesharing: 1.17.0
  - files: 1.22.0
  - files_reminders: 1.0.0
  - files_rightclick: 1.6.0
  - files_sharing: 1.19.0
  - files_trashbin: 1.17.0
  - files_versions: 1.20.0
  - firstrunwizard: 2.16.0
  - guests: 2.5.0
  - logreader: 2.12.0
  - lookup_server_connector: 1.15.0
  - nextcloud_announcements: 1.16.0
  - notes: 4.8.1
  - notifications: 2.15.0
  - oauth2: 1.15.1
  - onlyoffice: 8.2.4
  - password_policy: 1.17.0
  - photos: 2.3.0
  - polls: 5.4.2
  - privacy: 1.11.0
  - provisioning_api: 1.17.0
  - recommendations: 1.6.0
  - related_resources: 1.2.0
  - serverinfo: 1.17.0
  - settings: 1.9.0
  - sharebymail: 1.17.0
  - support: 1.10.0
  - survey_client: 1.15.0
  - systemtags: 1.17.0
  - text: 3.8.0
  - theming: 2.2.0
  - theming_customcss: 1.15.0
  - twofactor_backupcodes: 1.16.0
  - twofactor_totp: 9.0.0
  - updatenotification: 1.17.0
  - user_ldap: 1.17.0
  - user_status: 1.7.0
  - viewer: 2.1.0
  - weather_status: 1.7.0
  - workflowengine: 2.9.0
Disabled:
  - encryption: 2.15.0
  - federation: 1.17.0 (installed 1.9.0)
  - files_external: 1.19.0
  - files_pdfviewer: 2.8.0 (installed 2.1.0)
  - suspicious_login: 5.0.0 (installed 4.1.0)
  • When did this behaviour start: I don’t really know! It was faster before, but I cannot say when.

Under your browser console, check (or provide) the output of the Network tab ti identify the specific transactions that are slow.

Your config indicates you are using a proxy. Where does your SSL/TLS (HTTPS) terminate?

trusted_proxies in config.php contains the following entries:

  'trusted_proxies' =>
  array (
    0 => '127.0.0.1',
    1 => '::1',
  ),

Apache does the https encryption. There’s no other proxy that I can think of. It listens on both port 80 and 443, does a redirection to port 443 using Letsencrypt certificates and serves files from DocumentRoot.

Here’s a screenshot of the Network tab in Developer Tools. It shows that it’s mainly waiting for core-common.js. Is this what you meant?

I see that other files are “cached”. Why not this large file? Is this normal?

No, not normal.

  • /login is as expected
  • /core-common.js?* should be cached[1]
  • The rest are as expected

If you click on the /core-common.js.* entry there when it’s not cached - which it sounds like is every time for you for some reason - you should be shown the headers. Under Response headers what is the Cache-control value for that entry?

Also, what is Cache-control for one of the ones that is being cached (for comparison).

Normally it would be this for all of those:

Cache-control: max-age=15778463, immutable

The weird part isn’t that it’s missing (there are various things that I can think of that might cause that, but that’s it’s impacting only 1-2).

Are you running your Nextcloud on your localhost by chance (i.e. on the same device you’re accessing it from)? Try removing that trusted_proxies configuration in your config.php. It shouldn’t be there anyway if you don’t have a proxy on your Nextcloud server.

Is your .htaccess in your installation (not data) directory up-to-date? If you did a manual update of Nextcloud maybe it got overlooked? It should have a section that looks exactly like this:

# Add cache control for static resources
  <FilesMatch "\.(css|js|mjs|svg|gif|png|jpg|ico|wasm|tflite)$">
    <If "%{QUERY_STRING} =~ /(^|&)v=/">
      Header set Cache-Control "max-age=15778463, immutable"
    </If>
    <Else>
      Header set Cache-Control "max-age=15778463"
    </Else>
  </FilesMatch>

  # Let browsers cache WOFF files for a week
  <FilesMatch "\.woff2?$">
    Header set Cache-Control "max-age=604800"
  </FilesMatch>
</IfModule>

If you hadn’t confirmed in multiple browsers I’d suspect an overriden browser.cache.* parameter in your browser settings (e.g. it defaults to ~50MB per asset in Firefox). So this seems something server-side.

Footnotes:

[1] Unrelated: The 15000ms indicates the effective end-to-end download link bandwidth capacity between you and your server is ~8-10 Mbit/s. Is that about accurate?

1 Like

Hi! Your footnote regarding effective end-to-end download speed got me thinking, and I finally found out what’s wrong: Somebody enabled the Apache module bw, for bandwidth limitation… as soon as I disabled it, the system was fast again!!

Thank you very, very much for your help! It is greatly appreciated.

3 Likes