https.so %cpu usage

[KottV]

Hi I found that with mcws running there is high cpu eating by plasma subprocess "http.so". It's around 2% on 8 cores or 17% per core. I use openSUSE TW with Plasma 5.12.4 and KDE FW 5.44

[noee]

Yes, I too have the issue with master and prev versions and I am currently looking for the reason. It has something to do with the XmlHTTPRequest object not cleaning up properly.

[noee]

Do you know how long it takes after the plasmoid connects to MCWS until the http.so processes start to eat the CPU?

[KottV]

Not sure. Sometimes - immediately. But now, I just killed process and wait when new instance start to eat, but usage is still (for minute or so) normal.

[KottV]

hmm, it does not connects to mc

[noee]

Also, try setting the update interval (Config/Connections) to a higher number, something higher than 8 and see what happens.

[KottV]

Yes, it works. I set 5 sec interval.

[noee]

KottV: Have you noticed any change in the CPU utilization?

I've moved the xhr requests into a js file to see if that changed the garbage collection as xhr objs come and go, but I don't think it matters. Bottom line, I am creating a new xhr obj with every zone poller call, which occurs on the update interval set in Config. With many zones and a small update interval, this could get be a little heavy if all of those zones are playing. Non-playing zones are only polled every 5 ticks of the update interval.

One thing I can try is to create an xhr obj for each zone that is then never out of scope and only used for polling and would only be GC'd when the mcws connection is dropped.

[KottV]

Have you noticed any change in the CPU utilization?

Of course. Now there are several processes with ~4%CPU total.

[noee]

mcwsremote-v1.11.99.zip

Install this version, stop all playback and run and connect to your host. Don't start any playback. After about 10 min, you should see http.so processes equal to the number of zones you have on the connected host and there should be 0% CPU from each of them.

Is that what you see?

[KottV]

What should I see if I have one zone only?

[noee]

On connect and plasmoid startup, with one zone, you should see 3-5 http.so processes almost immediately, but only one of them will be polling the host for that zone. The others should be idle and after about 10 minutes or so, will clean up and disappear, so at that point, you should have only one or two http.so showing.

This is assuming no playing zones.

[KottV]

Same consuming 4-5% by one process

[noee]

What is your update interval? What type of hardware is the plasmoid running on? Is your MC host on a remote server or is it localhost?

[KottV]

I don't think it's relevant:

2 sec (because it was new install) AMD FX8120, 8GB RAM, SSD localhost

[noee]

Yeah, just checking. I have another thing to try, I will get you a test version here soon.

[noee]

Pls try this test, it will show some timings on the console for a the poller update queries. On startup, you'll also see track details timings. Basically, for a localhost, you should not see anything > 10ms or so on the poller update for your playback zone.

Install the plasmoid, then open a console and run it in plasmoidviewer:

plasmoidviewer -a org.kde.mcwsremote mcwsremote-v1.11.99.zip

[KottV]

Yes. It's around 9 ms

Player: 8ms Player: 13ms Player: 9ms Player: 9ms Player: 18ms Player: 9ms Player: 9ms Player: 9ms Player: 9ms Player: 9ms Player: 8ms Player: 8ms Player: 8ms Player: 7ms Player: 9ms Player: 9ms Player: 9ms Player: 10ms Player: 10ms Player: 9ms Player: 9ms Player: 8ms Player: 9ms Player: 9ms Player: 9ms Player: 10ms Player: 8ms Player: 10ms Player: 8ms Player: 8ms Player: 9ms Player: 9ms Player: 9ms Player: 9ms Player: 9ms Player: 8ms Player: 9ms Player: 9ms Player: 9ms Player: 9ms Player: 8ms Player: 9ms Player: 9ms Player: 9ms Player: 9ms Player: 9ms Player: 9ms Player: 9ms Player: 9ms Player: 8ms Player: 8ms Player: 8ms

[noee]

Okay, that looks normal. That's essentially round trip from creating the request, back to the point where the plasmoid model gets updated and is consistent with what I'm seeing in my environment.

The CPU% reported for http.so is something else going on, perhaps garbage collection, I'm not sure. Either way, this next release should be a little friendlier with the mcws polling.