We get a lot of performance-related questions about Untangle, and unfortunately sometimes there are no simple answers. There are several main components that determine the performance of your Untangle setup.
- Server Hardware
- Configuration
- Traffic Profile
Of course, all three of these are closely interrelated. I’ll explain how to tweak each one such that you can find a working configuration.
Hardware
While server performance is extremely complex and there are many different kind of resources, usually the most important resources that can be limiting factors are memory, CPU, disk I/O.
When people think of server performance they usually think of CPU speed. While CPU clock speed and processing power are important, they are the least important resource of these 3 for Untangle’s work set. More cores and faster cores help, but you can actually run a large site on a faily underpowered CPU if you have plenty of memory and disk I/O.
Memory is extremely important up to a point. You need enough memory to store Untangle’s working set with some left over to serve as disk cache for database I/O. If you have a major shortage of memory, you’ll see consistent swapping, performance will be sluggish, and pauses will occur. Once you have enough memory, you may want to add more for better disk cache, but you won’t see massive gains from doubling memory if you already have enough.
Currently, The most important resource for Untangle is disk speed or disk I/O (input/output). Unfortunately, when evaluating servers it is often overlooked and the hardest to quantify. Unlike a typical firewall which has flat log files, Reports runs a database and each application logs to the database through the reporting system. Systems experiencing disk I/O saturation can experience long pauses and major sluggishness.
Generally, I would just plan on having plenty of all 3 types of resources for your setup with some overhead available, just in case. It is absolutely essential to have at least enough of memory and disk I/O. You can have a 16 core machine with 16 gigs RAM, but if your disk is slow, that will ultimately be your limiting factor.
Virtualization can be a source of additional performance woes. If virtualized, make sure that Untangle has sufficient disk I/O. If other VMs running on the same virtualization platform manage to saturate the disk I/O, Untangle performance will suffer.
Configuration
Configuration obviously has a huge effect on the performance of your setup. Which apps are installed and their configuration has a huge impact on the amount of work the Untangle system has to do to process the network traffic.
Many new users expect Untangle performance to be comparable to other software firewall solutions available with similar hardware requirements. This is usually true if you install just the Firewall application and maybe Intrusion Prevention. Untangle will be slightly slower than your typical layer-3 firewall at these tasks because Untangle (by default) processes all sessions at layer 7, which means it reconstructs the stream for processing before deconstructing it again on the other side. However, you’ll probably find similar performance in throughput and latency with similar hardware requirements to other software firewalls with this configuration.
Where Untangle starts to diverge is when you start installing other apps that can have huge impact on the resource requirements. For example, Web Filter Lite requires a large amount of memory all by itself because it stores the entire categorization database in memory. Web Filter requires much less, since it does its categorization through a cloud service with a local cache. Reports, on the other hand, requires almost no additional memory ,but requires a huge amount of disk I/O to process and store events. The following chart provides a high-level guide to which resources and how much of each resource each app requires.
| Component/App | Memory | CPU | Disk I/O |
| Platform | medium | medium | medium |
| Web Filter | low | low | low |
| Web Filter Lite | high | low | low |
| Virus Blocker | medium | medium | medium |
| Virus Blocker Lite | medium | medium | medium |
| Spyware Blocker | low | low | low |
| Spam Blocker | medium | medium | medium |
| Spam Blocker Lite | medium | medium | medium |
| Phish Blocker | medium | medium | medium |
| Web Cache | medium | low | high |
| Banwdith Control | low | medium | low |
| Application Control | low | medium | low |
| Application Control Lite | low | medium | low |
| Firewall | low | low | low |
| Intrusion Prevention | low | medium | low |
| Ad Blocker | low | low | low |
| Reports | medium | medium | very high |
| Policy Manager | low | low | low |
| Directory Connector | low | low | low |
| WAN Failover | low | low | low |
| WAN Balancer | low | low | low |
| Captive Portal | low | low | low |
| IPsec VPN | low | low | low |
| OpenVPN | low | low | low |
| Attack Blocker | low | low | low |
| Configuration Backup | low | low | low |
| Branding Manager | low | low | low |
| Live Support | low | low | low |
Note: these are just an estimates. The configuration of the app itself can matter a great deal. For example, Reports with a data-retention time of 30 days can be significantly more costly than one configured with the defaults (7 days). Virus Blocker can require very little, but if configured to scan each .png downloaded over HTTP, it will be significantly more costly.
As mentioned, earlier no apps require an intense amount of CPU power; therefore, it is less important. Disk I/O and memory are very important. If you are short on Disk I/O, try disabling Reports, which will lessen the disk I/O requirements a significant amount. Likewise, if you are short on memory, try removing Web Filter Lite.
The other important aspect of configuration is bypass rules. By default, Untangle processes all ports of TCP and UDP at layer 7. For some setups, this is overkill, and significant gains can be had by just adjusting the bypass rules to bypass traffic that doesn’t require scanning. I’ll talk about this a bit in the next section.
Network
The type and amount of traffic on your network plays in important part in your Untangle performance. Unfortunately, it isn’t always a variable you can tune, but usually you can change the configuration to match your network profile.
If you have a large amount of traffic, you can tune a couple of things. If you look in Reports and you see a huge amount of traffic (either by # sessions or # bytes) to a port other than 80, 443, 53 and other common ports, consider bypassing it. For example, sometimes we’ll look at a site and see millions of sessions to port 514. Its doubtful that a site like this really needs to spend the server resources on scanning their internal syslog traffic (port 514). This traffic can safely be bypassed. Some sites can bypass UDP entirely depending on why Untangle is being used. If you are using Untangle for web filtering and reporting, you don’t even need to process UDP and can safely bypass it to improve performance.
In some cases, you can actually change the network profile. For example, schools often struggle with P2P and bittorrent saturating the bandwidth and causing performance bottlenecks at the WAN. Application Control and Bandwidth Control can provide essential tools for blocking or slowing unimportant traffic to limit both the bandwidth requirements and server resource requirements.
Performance Numbers
Users often request performance metrics be published by vendors. Untangle doesn’t play that game, and here’s why. Traditionally, network devices quantify network performance in throughput. Untangle doesn’t publish throughput numbers because it is obviously hardware-dependent, but, more importantly, because it’s just irrelevent. Even bare minimum hardware doesn’t have a tough time supporting 100Mbit, which is far more than most users running minimal hardware have at the gateway anyway. It doesn’t require a lot of hardware to support gigabit or 10 gigabit or more levels of throughput.
What matters a great deal is the type of traffic. For example, 100Mbit of continuous tiny HTTP fetches and tiny HTTP downloads requires significantly more work to process than one big HTTP download taking 100Mbit. However, at the packet level, both are just 100Mbit/sec of packets.
Another common metric is maximum number of sessions. Untangle also declines to publish these numbers because they are similarly useless. Vendors publish these numbers for their servers when they are “optimally” configured, which is a code word for configured for maximal performance and minimum utility. Publishing the performance of Untangle with traffic bypassed and no apps installed is not useful because no one runs it like that since it provides no utility in that configuration.
We did some internal testing of common appliances currently available. None of them even supported 10% of the advertised maximum number of sessions with a “reasonable” configuration. After reading, this if you’re still worried about the typical performance metrics, then rest assured that its fairly easy to configure your Untangle server to support 256k concurrent sessions and more than gigabit throughput on even the smallest of servers.
Summary
Hopefully this article helps illuminate some of Untangle’s inner workings and its performance characteristics.
Users often ask “How big of a server do I need on a site with X thousand users?” or “Is this server big enough for this site?”
Unfortunately these questions are impossible to answer as the difference from one site to the next site and one configuration to the next configuration can be drastic.
As general guidance, buying a server with good hardware, several cores, and a few gigs of memory, and a good disk setup can handle huge sites if configured correctly. If you aren’t sure how to configure it correctly, call Untangle support. If you aren’t sure what server to get, remember disk I/O is what matters. If you just want one you know will work, check out our appliances.
– Dirk
