Up to Main Index Up to Journal for January, 2021
JOURNAL FOR SUNDAY 31ST JANUARY, 2021
______________________________________________________________________________
SUBJECT: Now you can raise a bot army too!
DATE: Sun 31 Jan 20:16:30 GMT 2021
Time for an overdue update on what I’ve been working on for WolfMUD. First a
recap on the recent module changes, then onto some fun stuff. Before modules
my workspace looked like this:
gits
`-- WolfMUD
|-- bin
|-- pkg
|-- release
`-- src
`-- code.wolfmud.org
`-- WolfMUD.git
I always keep and organise my Git repositories under a gits directory in my
home directory. The WolfMUD repository always bothered me as it was actually
four directories down in the tree instead of at the top level, directly under
the gits directory. With module mode the workspace layout changed and I now
have:
gits
`-- WolfMUD.git
This is good and makes me happy, it’s how I would normally have things setup.
However, before module mode I had a bunch of utilities, makefiles and other
miscellanea under the gits/WolfMUD directory and outside of the public repo.
With module mode I had nowhere sensible to keep such files.
This is one reason why I took the time and effort to clean-up the Makefiles
and utilities I use and make them presentable enough to include them in the
repository for everyone to use. Having done so people wanted more, and have
been asking for me to include my botrunner as well…
Ah, the botrunner. The botrunner was written a long time ago, at the start of
the project. It simulated players logging into the server and running around.
It was a very useful tool for load testing. Alas it received no love, was very
flaky and at times could turn pathological and needed constant attention when
running. In short it was not fit to be included in the main repository. Over
the years many people have asked for a copy of botrunner. I either declined,
or sat down and very patiently explained all of its faults before handing over
any code.
Now all that changes. Over the last few weeks I’ve rewritten the bot runner
and added it to the repository under the tools package. I’ve also added a new
Bash script called ‘newAcct’ for easily creating player accounts from the
command line.
I still need to document the bot runner. For now, here is how you raise you
own bot army. First you need to create accounts for your bots:
>cd build
>seq 0 1027 | xargs -P2 -I+ ./newAcct BOT+ Bot+ BOT+
This will create 1028 bot accounts where the account ID is ‘BOT<n>’, the
password is ‘BOT<n>’ and the player name is ‘Bot<n>’. You can speed up the
account creation process by setting ‘-P2’ to the number of CPUs/Cores/Threads
your machine has.
To let your bot army lose on the server run:
>./botrunner -n 1024 -t 10
2021/01/31 19:01:46 Launching 1024 bots (0 - 1023), for 10 minutes
2021/01/31 19:01:51 Running...
The -n value is the number of bots to launch. The -t value is the number of
minutes the bots should run for. There is also a -o value for specifying an
offset for the bot number to start at. For example, to run two botrunner at
the same time (possibly from different machines[1]) you would use:
>./botrunner -n 512 -t 10
2021/01/31 19:06:28 Launching 512 bots (0 - 511), for 10 minutes
2021/01/31 19:06:31 Running...
>./botrunner -o 512 -n 512 -t 10
2021/01/31 19:06:49 Launching 512 bots (512 - 1023), for 10 minutes
2021/01/31 19:06:51 Running...
Now a few words of warning, so pay close attention. The botrunner can still
turn pathological. I’m working on the issue, which may turn out to be more of
a server/networking buffering issue. It manifests after the bots have been
running for a while and causes the server to take ages, sometimes minutes, to
return a response to a client. Second warning, do not run the botrunner with
more than a few bots if the server is compiled with the race detector — memory
usage will quickly go through the roof eating gigabytes in a very short time.
There is also a hard limit to the number of goroutines when running under the
race detector, which I think is about 8,000 goroutines.
I have found that the server runs a lot smoother with the following network
tweaks, applied as root at the command line:
sysctl net.ipv4.ip_local_port_range="1024 65535"
sysctl net.core.somaxconn=8192
sysctl net.core.netdev_max_backlog=8192
sysctl net.ipv4.tcp_max_syn_backlog=8192
sysctl net.ipv4.tcp_wmem=8192
sysctl net.core.rmem_default=8388608
sysctl net.core.wmem_default=67108864
One final warning, if you launch thousands of bots they will all start in one
of the three starting locations. This means there will be a high level of lock
contention in those locations and CPU usage will start a little high. This is
expected and will subside as the bots spread out to other locations. I highly
suggest that you modify the zinara.wrj file and set the tavern door to OPEN by
default, otherwise all of the bots will be stuck in the tavern. Find the
record for the door:
%%
Ref: L3N1
Name: the tavern door
Aliases: +TAVERN DOOR
Door: @ITEM EXIT→E
Narrative:
This is a sturdy wooden door with a simple latch.
%%
Then add ‘OPEN’ to the Door field:
Door: @ITEM EXIT→E OPEN
Here is an excerpt from the log with about 10,000 bots running around:
U[164Mb -19Mb] A[+24658065] O[1181111 -768374] T[10753 +0] G[10508 +0] P 10481
U[169Mb +4Mb] A[+22791214] O[1341643 +160532] T[10753 +0] G[10508 +0] P 10481
U[192Mb +23Mb] A[+21219003] O[2191993 +850350] T[10753 +0] G[10508 +0] P 10481
U[183Mb -9Mb] A[+19986775] O[1852003 -339990] T[10753 +0] G[10508 +0] P 10481
U[205Mb +22Mb] A[+18869885] O[2637064 +785061] T[10753 +0] G[10508 +0] P 10481
U[209Mb +4Mb] A[+18164494] O[2725236 +88172] T[10753 +0] G[10508 +0] P 10481
U[190Mb -19Mb] A[+17507477] O[2104977 -620259] T[10753 +0] G[10508 +0] P 10481
Don’t forget, you can login while the botrunner is running and see all of the
busy little bots at play :)
Please remember, the botrunner code is a work in progress. The botrunner
and/or server can turn pathological. I’m working on the issues and will post
updated code as soon as possible. If you’re happy with that, the changes are
now on the public dev branch.
--
Diddymus
[1] The botrunner is currently hard-coded to connect to 127.0.0.1 port 4001.
Up to Main Index Up to Journal for January, 2021