Hint for anyone reading this and not knowing what this is about: forget it, skip to something else. It may be outdated although it is less than a few days from now (most of it was written on 26.06.2019).
I documented it in this way to make it more likely for others to spot mistakes in the way I interpreted the logs.
Spoiler: with my setup csi_battery_saver is the winner.
1. What did I do?
Enable debug logging, two different sets of modules, each for about one day.
smacks, smacks_offline and cloud_notify where active in both setups. They differed regarding the set of csi modules used:
Day one: csi_battery_saver
Day two: csi_simple, csi_grace_period and csi_muc_priorities. All public MUCs joined by the test user are set to low priority for csi_muc_priorities (done using gajim). There is only one MUC left in normal priority, but it only has four members.
Both days where similar: mobile internet connection (no wifi) except in the middle of the period when being at home. Similar usage of phone while at work.
The log files where grepped using
grep -h to..user@domain/Conversations.random var/log/prosody/* | grep Sending.c2s | sort > /tmp/idsand the remaining timestamps where evaluated.
Most of the lines contain presences sent by MUC participants.
2. Results
2.1. Server logs
The first plot shows the difference in time between one line and the next (difference == 0 have been omitted, otherwise they’d completely fill the baseline). This plot clearly shows the differene between both setups…
…but I wanted to plot histograms nonetheless. First day, csi_battery_saver:
Second day, csi_simple and friends:
It seems that csi_battery_saver much better bundles the transmissions into bursts.
2.2. Android
During the days I noted what Android (Lineage 14.1 on a S4 mini) said about Conversations' (2.2.1, without push) battery usage and took some screen shots. Especially the time for mobile radio interface active (or whatever it may be called on english phones) went up much faster the second day (csi_simple and friends). Battery usage is clear, too:
I merged two screenshots to show quality of radio signal, wifi, phone active and display on. Marked areas correspond to the histograms shown above.
3. Code details
Changeset of community modules: da2d58208574 mod_muc_defaults: Allow setting of name and `description …
4. Notes
4.1. XEP-0286
Zash pointed me to XEP-0286:
-
It suggests Stream Compression (XEP-0138) which was https://prosody.im/doc/modules/mod_compression for prosody, now it is https://modules.prosody.im/mod_compression_unsafe.html Read the notes, don’t use 0138 because of security.
-
I guess XEP-0115 does not have a high impact.
-
XEP-0237 is active
-
XEP-0198 is active
-
XEP-0352 is active
-
XEP-0357 is active
-
XEP-0313 is active
So, other than maybe tweaking factory defaults or installing an unsafe 0138, there is nothing a prosody operator can do about it.
4.2. https://issues.prosody.im/1127
This bug was open and the reason why I didn’t use csi_battery_saver in the first place. But it actually seems to have been fixed some time ago:
Changeset: (75930e4c2478) mod_csi_battery_saver: flush queue on smacks resume instead of smacks hibernation
User: tmolitor
Date: 2018-06-08 17:39:43 +02004.3. Bugfix in mod_csi_muc_priorities
…some days after my tests: https://hg.prosody.im/prosody-modules/rev/2444fb3b05b7
However, Zash pointed out:
I think the poor performance there is caused by mod_smacks not working with mod_csi_simple, since it gets capped to ~60s after a while (probably a disconnect+resume) and mod_smacks has a 60s timeout.