Tom Mairs
3.9 KiB
Tuning for Performance
You can get better performance with some fine tuning of system parameters, The settings below are examples only but have worked in test and development servers. As the saying goes, "your milage may vary" so you should research these and tune as needed for your own system.
KumoMTA makes heavy use of files, RAM, CPU and network resources. Setting these can be helpful as a default Linux install assumes the need to share resources with many applications, but we need to allow KumoMTA to use as much of the resource pool as possible.
# Tune sysctl settings. Note that these are suggestions,
# you should tune according to your specific build
echo "
vm.max_map_count = 768000
net.core.rmem_default = 32768
net.core.wmem_default = 32768
net.core.rmem_max = 262144
net.core.wmem_max = 262144
fs.file-max = 250000
net.ipv4.ip_local_port_range = 5000 63000
net.ipv4.tcp_tw_reuse = 1
kernel.shmmax = 68719476736
net.core.somaxconn = 1024
vm.nr_hugepages = 20
kernel.shmmni = 4096
" | sudo tee -a /etc/sysctl.conf > /dev/null
sudo /sbin/sysctl -p |sudo tee -a /etc/sysctl.conf
Performance Test
OK, now lets really test this with some volume. You will not want to do that in the public internet with real addresses for a number of reasons, so you should set up another KumoMTA instance and have it run the included "sink.lua" policy. That will set KumoMTA to accept all messages and discard them without forwarding.
Once you have the second one configured, you can create a script on the sending server to loop over an injection to the sink as many time as you like. Using a function like 'time' can give you an accurate time windows and knowing the number of loops and size of email, you can determine performance.
Part of the packaged build is a "traffic Generator" that can be use to send volume test mail for this purpose. It will append a known domain to all outbound mail that resolves to your own loopback address so that mail can be delivered, but will never deliver to real addresses. You can use it like this:
sudo /opt/kumomta/sbin/traffic-gen --target <your.sink.server>:587 --concurrency 20000 --message-count 100000 --body-size 100000
Get more usage info with
sudo /opt/kumomta/sbin/traffic-gen --help
That traffic generator was used to test throughput before the initial release. There is a sample chart below of one done recently.
One handy setting for performance testing is custom routing. If you configure your sending server to route all messages to the sink server, and the sink is configured to dev/null all messages, that can make your testing script less complicated. IE:
kumo.on('smtp_server_message_received', function(msg)
msg:set_meta('queue', 'my.sink.server')
end)
Test Results
The test configuration was one "sending" configured KumoMTA in AWS (variable CPU and RAM) and one "sink" KumoMTA in Azure (8 CPU/16GB RAM) using a payload of 100KB sent in a loop 100,000 times. The test utilized the included traffic-gen utility described above.
| CPU | RAM | RATE |
|---|---|---|
| 2 | 4 | 2.7 MMH |
| 4 | 16 | 4.4 MMH |
| 8 | 30 | 4.9 MMH |
| 16 | 64 | 5.1 MMH |
NOTE that these numbers are NOT guaranteed and are for informational purposes only. Your results may vary considerably.
In July 2023 another round of testing was done with more detailed results. those results are shown in the table below and were documented in the blog post "How we built the most performant Message Transfer Agent on the planet"
Now What?
RTFM. Seriously. KumoMTA is a very powerful, highly configurable MTA that you can integrate in many ways. There is no way we can document every possible use case or configuration.