samba.git/source3/torture/msg_source.c, branch master

lib: Remove timeval_set()

2024-03-22T06:07:42+00:00

We have the same function in tevent, no need to duplicate code. More lines just
due to clang-format.

Signed-off-by: Volker Lendecke 
Reviewed-by: Andrew Bartlett 

Autobuild-User(master): Andrew Bartlett 
Autobuild-Date(master): Fri Mar 22 06:07:42 UTC 2024 on atb-devel-224

lib: Add lib/util/server_id.h

2017-01-22T17:30:11+00:00

Signed-off-by: Volker Lendecke 
Reviewed-by: Ralph Boehme

torture: Remove a use of get_my_vnn()

2016-05-16T21:23:53+00:00

Reduce the use of globals

Signed-off-by: Volker Lendecke 
Reviewed-by: Jeremy Allison 

Autobuild-User(master): Jeremy Allison 
Autobuild-Date(master): Mon May 16 23:23:53 CEST 2016 on sn-devel-144

s3:torture:msg: use lp_load()-wrapper lp_load_global()

2015-04-22T11:57:30+00:00

Signed-off-by: Michael Adam 
Reviewed-by: Ira Cooper

messaging3: Add msg_sink/source -- perftest

2014-08-22T22:24:18+00:00

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 
Reviewed-by: Jeremy Allison