there were some recent changes in trunk which made counter replies a bit “smarter”, while also requesting them a bit more often. i’m interested if anyone noticed any performance-related changes on their instances? more, less cpu usage, slower or faster counter updates, stuff like that.
I am the user with the 1.2mio unread articles from the other thread.
Unfortunately, I can no longer compare it directly because I have switched to a better VPS in the meantime and only have 400k articles after cleaning it up.
If I currently compare it with build 7f41228a7 to yesterday I would not say that it got worse. A spike in cpu usage when reading individual articles fast enough is still there.
Perhaps the shown “unread numbers” are refreshed very fast in web gui, almost realtime when i click on an article, but cpu usage is still there.
i’ll try to fill up an instance with more articles so i would have something to compare to. on everything i have (including a celeron mini “server”) tt-rss gives zero load. 
link removed
it looks like this from second 8 when i read 5 articles with 1s between each article.
these a 4 real Epyc 7702 Cores, not shared cores.
This is much better than it was before on old vps with 4 cores and 1.2mio articles. cpu usage was 100% when i click on 5 articles
this information (especially htop.gif) really doesn’t help in any way whatsoever.
the cpu usage is only there if i click on articles to mark them as read.
on my dev system when i choose “scroll to mark as read” and i scroll like a crazy idiot, there is almost no cpu usage.
are you using three panel mode or something? those might still not use conditional counters.
hm. dont know what this is
its defaults tinyrss, default theme, no customization. plugins only auth_internal, af_proxy_http:
can you make a video or something that shows tt-rss ui and what exactly you’re doing with it, preferably with browser f12 console open? or a screenshot?
e: no, same thing in three panel mode. there should be no difference between clicking on something and marking as read while scrolling, same thing that happens under the hood (mutation observer reacting on things and syncing information to the server)
without some kind of proper profiling information that doesn’t involve me trying to guess what you’re doing and what happens i won’t be able to help you any further.
i have send you a message with a simple video what i am doing.
I do not know if it is related, but I noticed that if I am logged to web interface twice at the same time (Firefox and Chrome for example) and start reading articles in one, the uread counter does not update on the second.
Earlier it was updated in the second istance once I selected an unread article.
why would you do that? anyway, counters are requested in full, periodically, once a minute. this is working as intended, i think.
I read most of the feeds while working remotely, so from home via a vpn, but the company’s firewall blocks some URLs, therefore I open those from the same machine, but outside of the working environment
I might be wrong, but earlier the counters were updated almost instantly between the two “sessions”.
yep, because all counters were calculated and dumped to frontend all the time. thus, the changes.
i’ve added an option (in advanced section) that disables conditional counters if needed.