This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

IPS benchmarking / performance testing discussion

Hi,

I've created a new 'sticky' thread for IPS performance benchmarks:
https://community.sophos.com/products/unified-threat-management/astaroorg/f/52/t/29110

Please comment or ask questions HERE.

Thanks,
Barry


This thread was automatically locked due to age.
  • It's extremely ironic that this was posted as I've been testing and perusing for an answer during the past hour. I recently discovered that although my trusty D525 Atom Box can achieve speeds of 111-120 Megabit down via BitTorrent, when I attempt to perform a Speedtest @ Speedtest.net, I can barely achieve 20-25 Megabit. Upload in both cases is rock solid between 33-38 Megabit. It's a 2 Processor w/ HT, and when cc set ips num_instances 0 is issued (default), it will spawn 3 Snort Processes. I've also tested it at 2 and 4, and I didn't see a difference with Speedtest.net.

    Is the reason that I can achieve high speeds with BitTorrent due to "Multiple Small Streams" whereas Speedtest is "One Large Stream"?
  • Hi,

    I can max out my 25mbps connection with BT with IPS, but speedtest.net only is hitting 16mbps with IPS.

    I have a single-core CPU with one Snort process, so in my case at least, the multiple-streams shouldn't be a factor.

    However, I believe (and see the test results I'm starting to post in the benchmark thread) that the PORT / service makes a huge difference.
    This makes sense as different snort rules apply to different ports, and there's probably a lot more rules on port 80 than on the random ports BT can use.

    I didn't realize the UTM was counting HT cores... in my testing on the Atom, more Snort processes than physical cores = worse performance.

    Barry
  • It seems that the port really does matter. Perhaps your assumption with regards to 80 being a highly filtered port makes sense as to why Speedtest.net yields such mediocre results.

    When I view the UTM with the UTM Manager, I definitely see four cores.

    I think it may be time to consider an ESXi Haswell Xeon Build and retire the lil' Atom that tried.

  • I think it may be time to consider an ESXi Haswell Xeon Build and retire the lil' Atom that tried.


    Yep. 
    I'm about to test my HP Gen8 MicroServer (Celeron 1610T), which is my ESXi server.

    If that performs well, I might get another one for the UTM, or use the same CPU on an Intel 1155 board.

    Otherwise, I'll probably get an i5-4670 for the UTM.

    The ESXi server will probably have the CPU replaced with a 45w Xeon, but I'm not sure I want to virtualize the UTM.

    Barry
  • What concerns would you have with virtualizing the UTM, given the ESXi was powered by an E3-1275v3 Haswell Xeon? That particular processor runs @ 3.5 GHz / 3.9 GHz Turbo. Quad Core w/ HT. I also believe it idles around 20 watts as an efficiency bonus.

    I'm all for bare metal, however, ESXi seems to really do a fantastic job of utilizing the hardware, and I don't see the UTM needing the full Xeon. Please correct me if that assumption is wrong.
  • A couple of concerns for myself:

    1. the ESXi server is a development & test machine, so I may be making a lot of changes to it, perhaps leading to an unstable system and thus an unstable network

    2. My HP cannot handle more than 16GB RAM, and I need about 12GB for my other VMs, plus overhead, leaving little room for the UTM.

    3. single point of failure, ...

    If those don't apply to / affect you, then go for it.

    Barry
  • 1. I plan to host the UTM, UTM Manager, a couple Linux Severs and the AWS for iPad monitoring. Shouldn't be too much flux on my end after that. Maybe a Sandbox VM once in a while.

    2. I'm aiming for 32 GiB, 8 of which will be dedicated to the UTM. 

    3. Instead of retiring the Atom, I could make it a Backup or Slave node in case of failure. Slave node may be tricky with how it's wired to the modem. May have to do research for that route.