Protip for someone in the future who will visit this topic:

DB keeps schemaDate (timestamp) and schemaLog (table), you can read this keys to check which schema upgrades are already applied.

topic can be closed

Hello again,
this issue is related to server/redis, NOT nodebb itself.
I have created dedicated Redis (3.0) cluster via Azure portal and seems to working fine from the 1hour.
I need to add rest of the plugins and check if they are not cause any issue but seems that problem was with the server/newest redis

So, interesting thing.
I have disabled execution of this query

"zscore" "uid:41843:followed_tids" "990614"

by hardcoding response of "Topics.filterWatchedTids" function (always return []).

Redis and CPU load decreased of about 50%

Next query on my list is:

1. 1. (integer) 369411
2. (integer) 1524255134
3. (integer) 291408
4. 1. "zrevrangebyscore"
   2. "topics:recent"
   3. "+inf"
   4. "1524082333364"
   5. "WITHSCORES"
   6. "LIMIT"
   7. "0"
   8. "-1"

which took about 0.3s to run and basically should be cached

@baris at redis monitor I see a lot queries like:
"zscore" "uid:41843:followed_tids" "990614"

What they mean ? User #41843 watching topic #990614 ?

@baris it seems that signed in user need some data from redis, but after nodebb upgrade redis stats looks not so good,
total operations increased from 9M to 25M per minute
CPU load from 40% to 100%
so yeach, that's the problem

There is also one more application entry via urstyle.pl (this domain has turned ON varnish for static files), urstyle.com is serving statics via nodebb as now, but it seems to not be a clue of the problem

@baris we are not loading categories at home page, there is even no request to nodebb /api endpoint (as a guest).
Yes, it's public (https://urstyle.com) you can compare page speed as a guest and signed in user.
There is 7M topic because we have about 7M subpages connected via nodebb-plugin-comments

@baris Performace is much much better for guests, but other hands worse for signed in users.
We have just upgraded nodebb from 1.5.1 to 1.8.2.

A guest visitor is able to get HTTP response from the homepage in 100-200ms, where signed in user need to wait for about 4-5s.
We have already 7M topics (not 1M) and probably some redis queries are not optimized

Protip for someone in the future who will visit this topic:

DB keeps schemaDate (timestamp) and schemaLog (table), you can read this keys to check which schema upgrades are already applied.

topic can be closed

Hello,
how can I force update again schema? When doing update my internet connection was shut down, I'm not able to run it second time because saying that everything is updated

@PitaJ we are now testing 10 instances instead of 20
@baris great tip! I didn't saw before this debug page, we don't have it visible in admin menu (nodebb 1.5.1). Now I see that only half of our instances getting the traffic - so there is a problem with loadbalancer.
We are serving static files via varnish cache.

Should we expect a huge performance difference between version 1.5 and 1.8 of nodebb?

Hello guys,
I'm looking for the ideas how to debug nodebb load.

Right now our nodebb application is using 200 registered users (400 connections with guests) online and we have about 1 million topics.
Unfortunately, our community receiving very often 503 (heavy load) error page, and application is very slow.

Our stack looks like:

• haproxy loadbalancer
• varnish (cache statics)
• nodebb loadbalancer
• 10 - 20 docker instances of nodebb running on two ports each

Everything of it is working on 3 hosts, from 13 to 27GB RAM and about 10% cpu load.

Where should we start to debug why nodebb is slow?

@julian @psychobunny