Using JMeter to load test a site outside a UTM I receive failure rates (caused by the inability to obtain a connection) of about 50%. Some requests are just fine. Some are just slow.
Performing the same test inside the UTM's LAN but hitting the LAN IP (not localhost or 127.0.0.1) of the node I'm testing and I get a 0% failure rate. The problem is coming from the UTM. I am looking for ideas on how to track down the bottleneck in the UTM.
I have the UTM configured with what I was hoping was a simple pass-through config:
Note no firewall config, no compression, no rewriting, no SSL. Should be simple.
UTM resources also don't appear to be an issue, as they barely fluctuate during the tests.
What am I missing with this? My understanding was that the UTM did not limit the number of connections, but clearly there is some kind of limit within the UTM that is not hardware-based.
Ideas on what I could check on this?
Really appreciate anyone's ideas.
-JM
This blog post appears to be relevant:
https://ewen.mcneill.gen.nz/blog/entry/2016-01-21-sophos-utm-reverseproxy-connections-per-second/
specifically this config:
/var/storage/chroot-reverseproxy/usr/apache/conf/mpm.conf
LoadModule mpm_worker_module /usr/apache/modules/mod_mpm_worker.so
ServerLimit 16
ThreadsPerChild 50
ThreadLimit 50
MaxRequestWorkers 800
MinSpareThreads 25
MaxSpareThreads 75
Does anyone know if Sophos has a recommended method for updating this config so that it survives a reboot?
This can be done by adding cronjobs executed @reboot. Here's what I just did on my lab UTM:
secure:/root # cat /var/storage/chroot-reverseproxy/usr/apache/conf/mpm.conf
LoadModule mpm_worker_module /usr/apache/modules/mod_mpm_worker.so
ServerLimit 16
ThreadsPerChild 50
ThreadLimit 50
MaxRequestWorkers 800
MinSpareThreads 25
MaxSpareThreads 75
secure:/root # cc set reverse_proxy 'max_processes' 32
1
secure:/root # cc set reverse_proxy 'max_threads_per_process' 200
1
secure:/root # cc set reverse_proxy 'max_spare_threads' 600
1
secure:/root # cat /var/storage/chroot-reverseproxy/usr/apache/conf/mpm.conf
LoadModule mpm_worker_module /usr/apache/modules/mod_mpm_worker.so
ServerLimit 32
ThreadsPerChild 200
ThreadLimit 200
MaxRequestWorkers 6400
MinSpareThreads 25
MaxSpareThreads 600
First, add the following lines to /etc/crontab-static:
@reboot root /usr/local/bin/confd-client.plx set reverse_proxy 'max_processes' 32
@reboot root /usr/local/bin/confd-client.plx set reverse_proxy 'max_threads_per_process' 200
@reboot root /usr/local/bin/confd-client.plx set reverse_proxy 'max_spare_threads' 600
Finally, set Up2Date to "Manual", [Apply], set it back and [Apply] in WebAdmin to force the lines into /etc/crontab. This will survive reboots, but is not included in a config backup.
Cheers - Bob
In effect, that's what this does, papa_. /etc/crontab-static is not ever touched by Up2Dates. The only time it's deleted is when a new system is loaded from ISO.
Cheers - Bob