![[OpenBSD]](../../images/smalltitle.gif)
[Previous: Logging]
[Contents]
[Next: Issues with FTP]
PF: Performance
"How much bandwidth can PF handle?"
"How much computer do I need to handle my Internet connection?"
There are no easy answers to those questions. For some applications, a
486/66 with a pair of good ISA NICs could filter and NAT close to 5Mbps,
but for other applications a much faster machine with much more
efficient PCI NICs might end up being insufficient. The real question
is not the number of bits per second but rather the number of packets
per second and the complexity of the ruleset.
PF performance is determined by several variables:
- Number of packets per second. Almost the same amount of processing
needs to be done on a packet with 1500 byte payload as for a
packet with a one byte payload. The number of packets per second
determines the number of times the state table and, in case of no match there,
filter rules have to be evaluated every second, determining the effective
demand on the system.
- Performance of your system bus. The ISA bus has a maximum bandwidth
of 8MB/sec, and when the processor is accessing it, it has to slow itself
to the effective speed of a 80286 running at 8MHz, no matter how fast
the processor really is. The PCI bus has a much greater effective
bandwidth, and has less impact on the processor.
- Efficiency of your network card. Some network adapters are just more
efficient than others.
Older rl(4) Realtek 8139 based cards tend to be relatively poor performers
(newer
re(4)-based Realtek cards are much better), while Intel 21143
(dc(4))
based cards tend to perform very well. For maximum performance,
consider using gigabit Ethernet cards, even if not connecting to gigabit
networks, as they have much more advanced buffering.
- Complexity and design of your ruleset. The more complex your
ruleset, the slower it is. The more packets that are filtered by
keep state and quick rules, the better the
performance. The more lines that have to be evaluated for each packet,
the lower the performance.
- Barely worth mentioning: CPU and RAM. As PF is a kernel-based
process, it will not use swap space. So, if you have enough RAM, it
runs, if not, it panics due to
pool(9) exhaustion. Huge amounts of RAM are not needed -- 32MB should be
plenty for close to 30,000 states, which is a lot of states for a small office
or home application. Most users will find a "recycled" computer more than
enough for a PF system -- a 300MHz system will move a large number of
packets rapidly, at least if backed up with good NICs and a good ruleset.
Will multiple processors help?
PF will only use one processor, so multiple processors (or multiple cores)
WILL NOT improve PF performance.
HOWEVER, under some circumstances, running the SMP version of OpenBSD
(bsd.mp) instead of bsd will give better performance
due to differences in how interrupt handling is done.
In many cases, bsd.mp will give less performance.
IF you are seeing performance problems, experiment with this, most users
will never hit any limits to worry about it.
Are there any benchmarks?
People often ask for PF benchmarks. The only benchmark that counts is
your system performance in your environment. A benchmark
that doesn't replicate your environment will not properly help you plan
your firewall system. The best course of action is to benchmark PF for
yourself under the same, or as close as possible to, network conditions
that the actual firewall would experience running on the same hardware
the firewall would use.
PF is used in some very large, high-traffic applications, and the developers
are "power users" of PF. Odds are, it will do very well for you.
[Previous: Logging]
[Contents]
[Next: Issues with FTP]