summaryrefslogtreecommitdiff
path: root/source3/torture/msg_source.c
AgeCommit message (Collapse)AuthorFilesLines
2024-03-22lib: Remove timeval_set()Volker Lendecke1-2/+6
We have the same function in tevent, no need to duplicate code. More lines just due to clang-format. Signed-off-by: Volker Lendecke <vl@samba.org> Reviewed-by: Andrew Bartlett <abartlet@samba.org> Autobuild-User(master): Andrew Bartlett <abartlet@samba.org> Autobuild-Date(master): Fri Mar 22 06:07:42 UTC 2024 on atb-devel-224
2017-01-22lib: Add lib/util/server_id.hVolker Lendecke1-0/+1
Signed-off-by: Volker Lendecke <vl@samba.org> Reviewed-by: Ralph Boehme <slow@samba.org>
2016-05-16torture: Remove a use of get_my_vnn()Volker Lendecke1-2/+3
Reduce the use of globals Signed-off-by: Volker Lendecke <vl@samba.org> Reviewed-by: Jeremy Allison <jra@samba.org> Autobuild-User(master): Jeremy Allison <jra@samba.org> Autobuild-Date(master): Mon May 16 23:23:53 CEST 2016 on sn-devel-144
2015-04-22s3:torture:msg: use lp_load()-wrapper lp_load_global()Michael Adam1-1/+1
Signed-off-by: Michael Adam <obnox@samba.org> Reviewed-by: Ira Cooper <ira@samba.org>
2014-08-23messaging3: Add msg_sink/source -- perftestVolker Lendecke1-0/+157
With this pair of programs I did some performance tests of the messaging system. Guess what -- I found two bugs :-) See the subsequent patches. With 1500 msg_source processes I can generate message overload: A Intel(R) Xeon(R) CPU L5640 @ 2.27GHz can receive roughly 100k messages per second. When using messaging_read_send/recv user/system time is roughly even, a bit more work done in user space. When using messaging_register, due to less malloc activity, user space chews a lot less. By the way: 1.500 helper threads in a blocking sendto() against a single datagram socket reading as fast as it can (with epoll_wait in between) only drove the loadavg to 12 on a 24-core machine. So I guess unix domain datagram sockets are pretty well protected against overload. No thundering herd or so. Interestingly "top" showed msg_sink at less than 90% CPU, although it was clearly the bottleneck. But that must be a "top" artifact. Signed-off-by: Volker Lendecke <vl@samba.org> Reviewed-by: Jeremy Allison <jra@samba.org>