22.2.3 Slower Initial Login? Local Accounts? Write Heavy to MySQL?

Just wondering if anyone else has noticed this, but from 22.2.2 to 22.2.3 local logins seem slower (significantly, say 2-5 seconds to 20+ seconds), and LDAP-based logins that always were a little slower are now super fast.

No changes on this test server, not the beefiest, but as a solo user except when demoing it I noticed. (2 cores, 4GB, FPM and MySQL stand alone, and, lots of workers, opcache, apcu, and large buffers for the MySQL). Not using redris. And it was fine, but now???

IOPS seem much higher for longer (I could always almost pin them before during login… standard azure disk with 600 IOPS), but wasn’t an issue with just one user(me). That seems to be the highest always, login.

Now, 300-500 for the entire time the login is happening. Lots and lots of disk writes (file locking?). Then calms down to single and double digits.

Not so with an LDAP-based account. a momentary spike to 300+ IOPS. Even after the page has loaded. Then calms down to single and double digits.

iotop shows the same story. LDAP login puts mysqld to the top for the length of the login, local admin account does the same for longer than the login by a few seconds.

All three processes restarted (php-fpm, apache, mysql) and later a full reboot. Same behavior.

Wish I had Jmetered nc22.2.2 (and it was just a couple, to the login screen and then the actual login, then entering a share)

Makes me wonder if the 22.2.1 fix applied to one class of user but not the other?

All my shares are remote sftp.

Just asking, and curious.


If there is a hiccup, I’m glad it was in LDAPs favor (local user is just the admin), but I noticed it. See timing for single user and 5 users (with 5 second ramp up). Clearly I am IO bound with the 5 local, but NOT the 5 LDAP users.

Getting errors trying to upload 22K jpegs of the appropriate section reports… ugg… have to type.

Login Attempt is when I am sending Creds.
Login View is just loading the login page to see what happens speed wise.
List Remote Dirs is just NC All Files Folder. Multiple sftp shares. LDAP has more actually.

One Local User

Page Min Max Average
Login View: 0.6 secs
Login Attempt: 22.6 secs
List Remote Dirs: 0.4 secs

Five Local Users

Page Min Max Average
Login View: 0.09 secs 0.6 secs 0.2 sec
Login Attempt: 45.5 secs 47.6 secs 46.5 secs
List Remote Dirs: 0.4 secs 0.5 secs 0.5 secs

One LDAP User

Page Min Max Average
Login View: 0.1 secs
Login Attempt: 1.8 secs
List Remote Dirs: 0.4 secs

Five LDAP Users

Page Min Max Average
Login View: 0.1 secs 0.2 secs 0.1 sec
Login Attempt: 1.3 secs 1.5 secs 1.4 secs
List Remote Dirs: 0.08 secs 0.1 secs 0.09 secs

Kinda interesting numbers…

Nextcloud seems to have resolved this with NC23 dramatically.

90% decrease in writes on login (300 per second for several seconds to 30-50 once) and much much faster login.

Edit: I Jmetered the old one and was able to make MySQL “go away” at 25 users hammering it simultaneously. Not an issue at all with the new product, ldap or local accounts and login time doesn’t go up to minutes anymore just from one sec with no load to two seconds with load). 2CPU/ 4GB Ram.

Not sure if there is a comment about this somewhere in the readme but suspect is has something to do with this:

Hi, if you still have that problem with the slow login:

Delete the content of oc_authtoken table for all users (or just for a certain user if you like)
Then the login will be very fast again.


1 Like

Ty… seems that NC23 resolved the issue and the writes dropped dramatically.

Could you please explain how to do it safely?

I also have the same problem. On my raspberrypi 4 (nextcloudpi) performance is generally quite good, but slow login page really annoys.

@rusangl Curious, what version and what kind of login? (ldap or local). And how long?

Version 22.2.2.
I don’t use ldap. Only 3 users use this server.

In about 3-6 seconds appears blue bar in the top, but full page loads in about 15 seconds. Then everything loads fast enough. There is no such thing while using android app.

i should notice that my instance now is about 7500 km away from me, but it seems there is no difference from where to connect. Also I have made some improvements according to the docs exept http2. That time I was experimenting with collabora office and didn’t realize soon enough that collabora app slows all my instance painfully. Then I found that my php updated suddenly from 7.4 to 8.0 and I decided to continue using 8.0. May be this also affects the whole system performance.

you could do it in the database by connection with phpmyadmin or similar or on the console with “mysql” if you use this as a backend.

The sql commadn would be:
delete from oc_authtoken;

You just have to sign in again with your devices then, thats it.

Or you could have a look in your “Settings” → “Security” and have a look at the list
“Devices and Sessions” (I hope its the correct translation)
You can delete them there as well.

We had this issue with our Nextcloud instance, login times up to one minute, after we deleted the tokesn, login was possible within 3-4 seconds again.

Hope that helps.