CPU Usage Browser (huge) vs. Iphone App (lite)

1

First sorry for my english, its not perfect…

I am using TinyRSS on my VPS for very long time… 4cores, 8gb ram, all SSD.

I am using latest TinyRSS Version on Debian 10, PHP 7.3.19-1~deb10u1, Apache/2.4.38 (Debian), PostgreSQL 11.7 (Debian 11.7-0+deb10u1)

I have 398 Feeds, 1.178 mio articles, ~4000 new articles (48h)

First i am very happy with my tinyrss system, its really fast for these numbers, but what is see between cpu usage with browser and app i cannot explain to me.

When i read “new articles” in browser and click on them (i click on single news items one after the other), all 4 cores are complete maxed out. Every single click does heavy on cpu (postgres: 11/main: tinyrss tinyrss 127.0.0.1(38238) SELECT

When i read my “new articles” on iphone app, there is almost no cpu usage on my vps.

Yes… i know over a million articles is a big number :smiley: but whats the difference here between any desktop browser reading and app reading?

i will add a picture: e.g. i click on the two news items to mark them as read -> high cpu usage

tinyrss
tinyrss1477×814 126 KB

2

if this happens on every click and when marking things as read, my guess would be counters being recalculated being the cause, it can be an intensive operation on a large dataset. API clients work differently and have to request counters manually, which would likely explain the difference in system load.

you can try enabling statement logging in postgresql to see the difference in queries while using the app or web ui.

3

Couldn’t that be something that could be optimized for everyone? The difference is huge.

4

i’m not going to invent hacks or compromise ui experience because of digital hoarders.

try keeping less articles until your hardware starts to keep up.

5

thats ok. i like ttrss.

but this is not a hardware thing. i can get 10 cores @ 100% only when i read some articles fast and mark them as read.

but this seems to be only my problem. Understandable that you don’t change anything if it doesn’t bother anyone else.

6

You have 1.1M unread articles. Heaven knows how many read you have on top of that. And if the former isn’t the problem, the latter certainly will be.

I currently only have only 500 unread, 18K total.

7

There should not be so much read articles in my database.

I set it to “delete articles older than 7 days”, but not delete unread articles.

8

if you don’t mind dumping your database (postgres only, just in case) and PMing me the link, i can poke around at it when i have some idle time.

9

i will try out with lower number of articles.

i cloned my ttrss lxc container and let this test instance run with delete 30 days older read AND unread articles.

i am wondering how many users and articles other users have in their tinyrss system :slight_smile:

10

btw i don’t know if you’re using docker setup or not, but out of the box postgres is very conservative with resource usage. on your huge dataset it’s something that you might want to tweak. work_mem, etc.

11

I am not using docker, but this is something i can try out too, thanks.
I will play with some postgresql memory settings.

I am using:

Apache/2.4.46 (Debian) with mpm_event
PHP-FPM 7.4.15
Postgresql 13.1 (Debian 13.1-1+b1)

but with defaults settings on postgresql.

12

I will rearrange my TinyRSS and reduce it a bit, but I won’t achieve much by doing so.

Is there no solution to set a deletion time for unread articles per feed?

I can only set the time per feed, but the setting for unread articles can only be included or excluded globally.

That would help a lot if you could set certain feeds so that unread articles are only saved for 14 days, for example.

I could set the global delete time to e.g. 365 days for unread and read articles and then set the time per feed to lower values if i want. but then read articles are stored for 365 days what i dont need…

i need unread articles flexible time, read articles as short as possible.

13

i’ve just pushed some counter-related changes which may improve things (or make them worse)