This is a topic I have read quite a few posts about, but I haven’t found a cause or solution. I am about a month into working with Nextcloud, starting with 27.0.2 to the now current 27.1.2. I have Nextcloud set up on a test box as a normal web application and I have worked with the config to enable all recommended transactional locks and caching and I have eliminated all warnings. The Admin “Overview” checks report “All checks passed”. Nextcloud carries out all operations brilliantly (no warnings of errors in any of the server or Nextcloud log files).
The problem is page-load times are frustratingly slow. Clicking any of the apps in the menubar results in a consistent 5 second delay before the information is shown. That’s a pretty long wait, 1-1000, 2-1000, 3-1000, 4-1000, 5-1000… Photos is a little better at just over 4 seconds, but there are only 3 images total. Task is likewaise a little better at about 4 seconds, but there are only 2 test-tasks entered.
The box is an older Core2 Duo, so not snappy, but fine for test purposes and no reason page-load times should not be a reasonable 1 second or less. I run other similar web applications (with the exact same contacts and calendar entries also in a MariaDB database) and there is no problem with page-load times (all pages are generated and shown in sub-1-second times, including the same contacts and calendar entries). This is something unique to Nextcloud.
I have looked over a number of related links below and I have collected the information that was requested in the other posts to try and sort out where the issue is. The links are:
Related Links
- My local Nextcloud is too slow in any response
- Nextcloud web-interface too slow
- Nextcloud Web UI EXTREMELY Slow
- Nextcloud is inconsistently slow (30+sec loading time, or only 2)
The crux of the other posts is 4G of RAM on a lightly loaded x86_64 server with only a few users should be fine. I am the only user and I’m accessing the server over a gigabit LAN, so network I/O isn’t an issue. The server, while not exposed publicly, has a 300 MBs internet connection. The details of the install follow.
OS / Server Software
Nextcloud is installed as a normal webapp on the host web-server, not inside a container or any other virtualized install that would add overhead. The server software running on this small Dell test-box is:
Nextcloud : 27.1.2
Archlinux : 6.5.5-arch1-1
Apache : 2.4.57 (Unix)
OpenSSL : 3.1.3
mod_fcgid : 2.3.9
PHP : 8.1.23
PHP-APCu : 5.1.22
Redis : 7.2.1
memcached : 1.6.21
Hardware
This is an old Dell computer I use as a test or prototype box before migrating apps to a production server. It’s a slow old Core2 Duo with 4G and a WD Carvair Blue internal SATA-III drive. While it is simply an old test box, it should be more than enough to get reasonable page-load times from Nextcloud. With similar web applications (eGroupware, etc…) all page loads are less than 1 second. This is using the same contacts (approximately 600 contacts) and calendar information (less than 5 current entries) in MariaDB databases. In fact the calendar and contacts in Nextcloud were imported from eGroupware.
Note, the page-load times did not change significantly between the time the Nextcloud database was empty and after the contacts and calendar entries were imported. Contacts was the most impacted which added another second or so for the 600 contacts.
The following is the information requested in the related links above that may impact page load-times:
CPU type : Intel(R) Core(TM)2 Duo CPU E7300 @ 2.66GHz
How much RAM : 4G
Network speed : LAN-Gigabit/GAT6, Internet-300 MBs
Hard disk : Internal SATA-III, Western Digital Caviar Blue Serial ATA
How many users : 1
Office suites : None
Other services : None
System Load : (top output below)
top - 02:21:12 up 23:57, 1 user, load average: 0.08, 0.02, 0.01
Tasks: 135 total, 1 running, 134 sleeping, 0 stopped, 0 zombie
%Cpu0 : 0.0/0.0 0[ ]
%Cpu1 : 0.0/0.0 0[ ]
MiB Mem : 23.1/3844.1 [|||||||||||| ]
MiB Swap: 0.0/1219.9 [ ]
Per the MariaDB recommendation in Configuring Swappiness I have set vm.swappiness=1. There is no paging to swap taking place.
The File Access Restriction app is NOT installed – that was mentioned as a possible cause for slow page-loads in the Version 15-16 timeframe. I don’t even see that app available to install any more.
This test box is at idle waiting to serve Nextcloud requests. That is a primary reason the slow page-load times are of particular concern. There isn’t anything else running competing for CPU time. I could see the box being the culprit if the cores were saturated or the RAM exhausted, but that’s not the case. Nextcloud has complete access to all the CPU with well over half the RAM available for use.
Nextcloud Config
{
"system": {
"datadirectory": "***REMOVED SENSITIVE VALUE***",
"logfile": "\/var\/log\/nextcloud\/nextcloud.log",
"default_locale": "en_US",
"default_phone_region": "US",
"knowledgebaseenabled": true,
"apps_paths": [
{
"path": "\/usr\/share\/webapps\/nextcloud\/apps",
"url": "\/apps",
"writable": false
},
{
"path": "\/var\/lib\/nextcloud\/apps",
"url": "\/wapps",
"writable": true
}
],
"trusted_domains": [
"localhost",
"2pi.3111skyline.com",
"192.168.6.111"
],
"overwrite.cli.url": "https:\/\/2pi.3111skyline.com\/nextcloud",
"htaccess.RewriteBase": "\/nextcloud",
"passwordsalt": "***REMOVED SENSITIVE VALUE***",
"secret": "***REMOVED SENSITIVE VALUE***",
"dbtype": "mysql",
"version": "27.1.2.1",
"dbname": "***REMOVED SENSITIVE VALUE***",
"dbhost": "***REMOVED SENSITIVE VALUE***",
"dbport": "",
"dbtableprefix": "oc_",
"mysql.utf8mb4": true,
"dbuser": "***REMOVED SENSITIVE VALUE***",
"dbpassword": "***REMOVED SENSITIVE VALUE***",
"installed": true,
"instanceid": "***REMOVED SENSITIVE VALUE***",
"mail_from_address": "***REMOVED SENSITIVE VALUE***",
"mail_smtpmode": "smtp",
"mail_sendmailmode": "smtp",
"mail_domain": "***REMOVED SENSITIVE VALUE***",
"mail_smtphost": "***REMOVED SENSITIVE VALUE***",
"mail_smtpport": "25",
"maintenance": false,
"app_install_overwrite": [
"issuetemplate"
],
"theme": "",
"loglevel": 2,
"memcache.local": "\\OC\\Memcache\\APCu",
"filelocking.enabled": true,
"memcache.distributed": "\\OC\\Memcache\\Redis",
"memcache.locking": "\\OC\\Memcache\\Redis",
"redis": {
"host": "***REMOVED SENSITIVE VALUE***",
"port": 0,
"timeout": 0
}
}
}
Nextcloud Enabled Apps
The apps are the standard set of apps that come enable with the Archlinux install. The only app I have added is the “theming_customcss” – though currently there is no custom CSS configured. The apps and versions I have are:
Enabled:
- activity: 2.19.0
- calendar: 4.5.2
- circles: 27.0.1
- cloud_federation_api: 1.10.0
- comments: 1.17.0
- contacts: 5.4.2
- dashboard: 7.7.0
- dav: 1.27.0
- federatedfilesharing: 1.17.0
- federation: 1.17.0
- files: 1.22.0
- files_pdfviewer: 2.8.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
- groupfolders: 15.3.1
- 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
- password_policy: 1.17.0
- photos: 2.3.0
- privacy: 1.11.0
- provisioning_api: 1.17.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
- tasks: 0.15.0
- text: 3.8.0
- theming: 2.2.0
- theming_customcss: 1.14.0
- twofactor_backupcodes: 1.16.0
- updatenotification: 1.17.0
- user_status: 1.7.0
- viewer: 2.1.0
- weather_status: 1.7.0
- workflowengine: 2.9.0
Web Server Log / Errors
There are no web-server warnings or errors since the server reload. All Nextcloud menubar apps have been used since that time (great job!). The Nextcloud code is in really, really great shape.
[Thu Oct 05 21:41:31.602376 2023] [mpm_prefork:notice] [pid 421] AH00163: Apache/2.4.57 (Unix) OpenSSL/3.1.3 mod_fcgid/2.3.9 PHP/8.1.23 configured -- resuming normal operations
[Thu Oct 05 21:41:31.602423 2023] [core:notice] [pid 421] AH00094: Command line: '/usr/bin/httpd -D FOREGROUND'
That’s what makes the slow page-load times so puzzling. I’ve watched the server applications and their behavior in top during page loads and the only thing remarkable is that php-fpm seems to really hammer the CPU in several threads after the page request is made. It never saturates the CPU, but will consume 40-50% of CPU capacity for a brief second while Nextcloud is trying to serve the page.
Another area of high-demand by php-fpm is in contacts when simply scrolling the user-list down by a page or so (to the next 10-15 contacts) and then back. When that occurs all the initial bubbles disappear and are redrawn, apparently being regenerated which puts significant demand on the system for something that seems like a trivial act. I’m concerned the same type of time-consuming page-generation work is taking place for every page-load behind the scenes.
Is there anything else I can do to reduce page-load times on this test server? All caching is enabled, though with nothing paging to swap, there isn’t a whole lot of cache hits coming into play. Is there any way to find out if the Nextcloud framework is just spinning its wheels in places resulting in long page-load times? Is there some debug mode where we can add page-generation times to display as a nav-pane footer to keep track of the differences in application load times? Any ideas on how better to check on what is happening to see if things can’t be made a little snappier? Sorry for the flurry of questions, but I’ve been racking my brain on what to do or how to try and address this.
Don’t get me wrong, Nextcloud is well-written and working fine, it’s just rather painful to have to use the web interface (which is what I use a majority of the time). I’m also happy to get and post any additional information anyone thinks will be helpful. There is a solution somewhere.
All suggestions are welcomed.
