Many exceptions regarding how long transactions are taking following upgrade to NC29

Following upgrade to NC29, I see many exceptions in the log regarding transactions taking a certain amount of time, which I presume is considered too high by Nextcloud. For example,

[no app in context] Warning: Transaction took 1.009428024292s
PROPFIND /remote.php/dav/principals/users/[username]/
from 62.178.177.26 by [username] at 1 Jun 2024, 19:29:23

This is on a virtual host managed by ISPConfig, and ISPConfig, e-mail, and Nextcloud are the only things running on it.

ISPConfig itself considers that the server load is “OK”, being:

System load 1 minute: 0.99
System load 5 minutes: 0.59
System load 15 minutes: 0.41

I have not really any idea where to start looking for something which might cause poor performance and would appreciate any hints or suggestions.

This diagnostic message existed in earlier versions. However, in earlier versions the level of this message was lower and the user was not bothered by it. Starting with version number 29, the level of this message was increased and became noticeable with standard logging settings. Four days ago the level of this message was lowered again. In the future of updates with standard event logging settings, you will no longer be bothered by thinking about buying a more powerful and faster computer or hosting.

1 Like

Thanks, @zdv. It’s not so much, however, that I’m bothered by the messages or that I want them merely to go away.

I’m genuinely interested in what they’re trying to tell me. If I need to bump the specs of the virtual host, fine, but based on the server load I see it just doesn’t seem obvious that’s really what’s called for.

I do see slow performance in Nextcloud in general; e.g., logging in, calendar synchronization, etc.

Some of the background regarding the logging of those types of transactions: Performance considerations — Nextcloud latest Developer Manual latest documentation

The transactions themselves it is referring to are interactions with your configured database.

It can turn up opportunities to optimize code for the developers, but it could also indicate a slower database back-end in your environment.

based on the server load I see it just doesn’t seem obvious that’s really what’s called for.

Simple load average monitoring unfortunately don’t give you a good impression of the impact of brief transactions (the transactions are <5s while the load average is computed over >=60s). Ironically on a multi-user system with lots of transactions it does give an indication due to sheer numbers/averages, but on smaller deployments (i.e. only a handful of users), you may need to dive deeper.

A quick and dirty way is to monitor things in real-time with tools like htop, top, iostat, vmstat, etc. (and there are fancier tools for manipulating performance data, but that’s a whole different discussion).

Every user can study and pass the Relational Database Building exam with distinction and help in software development by pinpointing the exact location where the slow software problem occurred. The rescue of drowning people is the work of the drowning people themselves. For reference, I inform you that diagnostic messages about slow database transactions appear immediately after installing nextcloud. In fact, from the user’s point of view, there is no data in the system, but the system is already slowing down and happily notifying about problematic requests. Hence the question: what exactly is proposed to be tested with interesting tools? Developments of the developers? Is it possible to clarify the hardware requirements and bring these requirements into line with the current version of software developments?

For what it’s worth, I did discover one boneheaded mistake in my configuration which was probably not helping performance; log_level was set to 0, so I bumped it back to 2. Who knows how long I had it set to 0.

I also finally got around to configuring redis to connect via socket rather than localhost. Perhaps that will help a bit as well.

1 Like