Likes extension in combination with Auto Moderator slows down my Flarum

hrvoje_hr

The issue

Recently, after upgrading my Flarum forum from 1.4 to 1.6.2 I noticed that Flarum drastically slowed down. Especially posting when there are 10+ users active on forum (5-10 seconds to submit the post).

I have @askvortsov AutoModerator Extension enabled with 15+ rules which gives user badges from @JasperVriends User Badges extension upon rewarding users with a specific sum of likes (example, after rewarding the user with 10 likes, he gains a +1 badge, then after another 10 likes +2 badge, etc...). Only an Admin have permission to give likes, and he does that a few times per day at max.

Flarum works great when Likes extension is disabled and Auto Moderator enabled

Flarum works great when Likes extension is enabled, but Auto Moderator is disabled

Flarum worked great with both extensions enabled on 1.4ž

Does anyone have a theory about what happened in the transition to 1.6.2?

Flarum information

Flarum core 1.6.2
PHP version: 7.4.30
MySQL version: 5.5.5-10.4.20-MariaDB-1:10.4.20+maria~buster-log
Loaded extensions: Core, date, libxml, openssl, pcre, zlib, filter, hash, pcntl, Reflection, SPL, session, standard, sodium, mysqlnd, PDO, xml, apcu, bcmath, bz2, calendar, ctype, curl, dba, dom, enchant, mbstring, FFI, fileinfo, ftp, gd, gettext, gmp, iconv, igbinary, imagick, imap, intl, json, exif, mongodb, msgpack, mysqli, odbc, pdo_dblib, PDO_Firebird, pdo_mysql, PDO_ODBC, pdo_pgsql, pdo_sqlite, pgsql, apc, posix, readline, redis, shmop, SimpleXML, soap, sockets, sqlite3, sysvmsg, sysvsem, sysvshm, tidy, tokenizer, xmlreader, xmlrpc, xmlwriter, xsl, zip, Phar, memcached, ionCube Loader, Zend OPcache
+------------------------------+---------+--------+
| Flarum Extensions            |         |        |
+------------------------------+---------+--------+
| ID                           | Version | Commit |
+------------------------------+---------+--------+
| askvortsov-auto-moderator    | v0.1.2  |        |
| flarum-tags                  | v1.6.1  |        |
| flarum-lock                  | v1.6.1  |        |
| flarum-markdown              | v1.6.1  |        |
| v17development-user-badges   | v1.1.0  |        |
| kilowhat-wordpress           | 1.7.5   |        |
| fof-linguist                 | 1.0.4   |        |
| fof-byobu                    | 1.1.7   |        |
| flarum-likes                 | v1.6.1  |        |
| flarum-lang-english          | v1.6.0  |        |
| flarum-emoji                 | v1.6.1  |        |
| davwheat-inline-group-badges | 1.0.0   |        |
| askvortsov-rich-text         | v2.1.7  |        |
+------------------------------+---------+--------+
Base URL: /
Installation path: /
Queue driver: sync
Session driver: file
Mail driver: smtp
Debug mode: off

GreXXL

hrvoje_hr I don’t know why this would be connected to the Flarum version but you should definitely use a queue - at least database queues. If there are many actions happening when submitting the post this is expected to happen without a queue.

hrvoje_hr

I don't know as well, but it's happening on 1.6. and wasn't before. Everything was fine on previous Flarum versions, I'm on good VPS too, so I would rather revert back Flarum version instead of degrading user experience with database queues/redis

GreXXL

hrvoje_hr I think this might be due to some changes that have been made to introduce new functionality in 1.5.0. It’s important though that performance will always degrade the bigger and more active your community gets if you don’t run queues. For example if you have some people following a discussion and getting a notification - when posting you have to wait until all notifications have been sent. When using a queue this gets done in the background and you will see no lag when submitting a post.

Darkle

Yeah, totally agree with GreXXL. Even if you downgrade version, with your volume of users I think it would be quite advisable to configure queue/redis, with few users it has no impact (exactly the same performance with or without) but with many users is completely necessary, the experience shouldn't be degraded (I don't know if you say that for some reason) rather the opposite with peaks you will avoid server failures, especially with mail sending it can happen a lot that if there is a failure at the job the mail won't be sent.

hrvoje_hr

I understand you guys about importance of queing, but I'm talking here about the issue which made my forum drastically slower after the update in the same conditions.

It made my forum drastically slower even in the 3am when nobody's online. This case isn't about processes slowing down forum.

Darkle

hrvoje_hr Have you tried the php flarum criteria:recalculate command? From what you say individually the extensions work fine, it's like the interaction between both... Maybe there is something wrong with AutoModerator, I don't know if recalculating will do any good, have you tried it?

The next thing I would try is if it happens with a copy of the forum somewhere else, so we can rule out if it is something specific to the environment, MariaDB for example.

hrvoje_hr

Already tried with that command. I will try with copy of the forum on another server.

Thanks for trying to help, I appreciate.

Darkle

hrvoje_hr If it doesn't happen in another environment, that would be "good news" (matter of testing), as the only reported Likes bug is this one here (flarum/framework3585) and it doesn't seem to have anything to do with this either.

Otherwise I'd probably try to contact Askvortsov to see if he can take a look at what happened between 1.4 and 1.6 that affected AutoModerator.

hrvoje_hr

Darkle happened between 1.4 and 1.6 that affected AutoModerator.

Interesting about AutoModerator, it works perfectly well with all my other actions. And I have around 50 of them for counting posts, which should be countless times heavier than Likes actions, which fire only a few times a day.