29 Sep
2020
29 Sep
'20
7:05 p.m.
Vadim also requested comparison of performance with his systemd-journald log
target in teh same benchmark.
Pleae find the results below:
systemd-journald (raw=false)
[4, 8) 1427 | |
[8, 16) 331242 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
[16, 32) 95378 |@@@@@@@@@@@@@@ |
[32, 64) 2874 | |
[64, 128) 449 | |
[128, 256) 48 | |
[256, 512) 7 | |
[512, 1K) 1 | |
[1K, 2K) 0 | |
[2K, 4K) 0 | |
[4K, 8K) 0 | |
[8K, 16K) 0 | |
[16K, 32K) 0 | |
[32K, 64K) 0 | |
[64K, 128K) 0 | |
[128K, 256K) 0 | |
[256K, 512K) 0 | |
[512K, 1M) 0 | |
[1M, 2M) 0 | |
[2M, 4M) 0 | |
[4M, 8M) 0 | |
[8M, 16M) 0 | |
[16M, 32M) 0 | |
[32M, 64M) 0 | |
[64M, 128M) 0 | |
[128M, 256M) 0 | |
[256M, 512M) 0 | |
[512M, 1G) 0 | |
[1G, 2G) 0 | |
[2G, 4G) 81 | |
systemd-journald (raw=true)
[4, 8) 5477 | |
[8, 16) 576683 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
[16, 32) 143985 |@@@@@@@@@@@@ |
[32, 64) 3000 | |
[64, 128) 772 | |
[128, 256) 107 | |
[256, 512) 8 | |
[512, 1K) 0 | |
[1K, 2K) 0 | |
[2K, 4K) 0 | |
[4K, 8K) 1 | |
[8K, 16K) 0 | |
[16K, 32K) 0 | |
[32K, 64K) 0 | |
[64K, 128K) 0 | |
[128K, 256K) 0 | |
[256K, 512K) 0 | |
[512K, 1M) 0 | |
[1M, 2M) 0 | |
[2M, 4M) 0 | |
[4M, 8M) 0 | |
[8M, 16M) 0 | |
[16M, 32M) 0 | |
[32M, 64M) 0 | |
[64M, 128M) 0 | |
[128M, 256M) 0 | |
[256M, 512M) 0 | |
[512M, 1G) 0 | |
[1G, 2G) 0 | |
[2G, 4G) 48 | |
So we can see that both of these are actually quite good: Up to 1ms for almost all log
writes
in the raw=false case, and more or less the same order of magnitude for the raw case.
Both are much better than blocking stderr + systemd picking up stderr (where latencies
up to 128ms are observed at times.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)