traffic_replay tool generates traffic in order to measure the performance of a Samba DC. It can be used to test how well Samba will scale as the network increases in size. It can simulate multiple different hosts making multiple different types of requests to a DC, and so can be used to determine the point at which the DC becomes overloaded.
traffic_replay tool was added in Samba v4.8. Refer to its man page for more details on how to run it.
traffic_replaytool should only ever be run against a dedicated test DC. Do not run it against a live DC that is handling real network traffic.
The traffic_replay tool generates user and machine accounts for the traffic it generates. As the user-generation is quite slow, the generated accounts will hang around afterwards, so they can be reused for subsequent traffic_replay commands. The generated accounts are under a 'traffic_replay' OU, and account names are generally 'STGU-0-x' for users, 'STGG-0-x' for groups, and 'STGM-0-x' for machines. Use the
--clean-up option to remove these accounts.
Populating a large database
The traffic_replay tool's
--generate-users-only provides a convenient way to populate a large database with users and groups. If you want to use the tool for this purpose, here are some tips, applicable for Samba v4.10 onwards:
- It's much faster to run the command locally on the test DC and pass it the filepath of sam.ldb instead of the server-name. This means the tool writes directly to the DB, avoiding the need to perform every single operation over LDAP. To get the full benefit in speed, use
--option="ldb:nosync = true", which skips flushing the memmap after every write. However, only do this on a standalone DC, as otherwise there's potential for DB corruption if other operations (e.g. DRS replication) are happening in the background.
- Use the
--random-seedoption. As users are distributed randomly to groups, if you (or someone else) needs to rebuild the DB later, then you'll get the same user-group distribution.
- Use the
samba-tool group statsto view a summary of how the users were distributed amongst the various groups.
- Generating users is slow. If you're using a temporary VM, instead of re-generating the users each time you spin up a new VM, you can use the backup tool to create a snapshot backup-file of the database. You can then restore the backup-file on a new VM (insteqad of doing the
samba-tool domain provisionstep).
- If you are using developer testenvs, note that you can load the backup-files into a Customdc testenv.
- Note that assigning group memberships when adding additional users to an existing DB gets a bit complicated, e.g. going from 10,000 users to 20,000. So it may not distribute the group memberships how you expect.