Re: [pfSense Support] Performance problems
On Tue, Jun 1, 2010 at 9:59 PM, Chris Buechler cbuech...@gmail.com wrote: One other consideration with any HTTP load testing with stateful firewalls is to be careful with your methodology. (..) Is there a way to bypass the state tracking for a specific packet? -- Per Buer, Varnish Software Phone: +47 21 54 41 21 / Mobile: +47 958 39 117 / skype: per.buer - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] Performance problems
On Wed, Jun 2, 2010 at 5:36 AM, Per Buer pe...@varnish-software.com wrote: On Tue, Jun 1, 2010 at 9:59 PM, Chris Buechler cbuech...@gmail.com wrote: One other consideration with any HTTP load testing with stateful firewalls is to be careful with your methodology. (..) Is there a way to bypass the state tracking for a specific packet? You can change the state type to no state on any firewall rule. Ensure you have no state rules matching the reply traffic as well. I don't think that will make much difference though, the overhead isn't really in state tracking as much as it's in filtering in general. You're still running it through the packet filter. If you just want something really fast, disable PF entirely and you have a dramatically faster router that can't filter any traffic. That's the only thing that will be a considerable performance improvement. What kind of throughput are you seeing when the CPU is pegged? - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
[pfSense Support] Performance problems
Hi. We've installed pfSense 1.2.3 on a couple of Coyote Point 550i appliences and so far we're very happy. It has 2GB of memory and a Xeon 3000-something CPU. It's run to run some sort of FreeBSD so Nanobsd should be well supported. This week however, we started running some test through the firewall. We're stresstesting Varnish, a http accelerator. The problem is that the pfSense box seems to be the weakest link in the chain. Quickly we saw the state table run full. When we increased the size of the table we run out of CPU quite fast. Load (read using vmstat) jumps up to ~50. Is it probable that this is due to the overhead of state tracking? The book on pfSense doesn't really have any good advice and google hasn't turned up much. Is there a high performance tuning guide? TIA, Per. -- Per Buer, Varnish Software Phone: +47 21 54 41 21 / Mobile: +47 958 39 117 / skype: per.buer - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] Performance problems
On Tue, Jun 1, 2010 at 2:08 PM, Per Buer pe...@varnish-software.com wrote: Hi. We've installed pfSense 1.2.3 on a couple of Coyote Point 550i appliences and so far we're very happy. It has 2GB of memory and a Xeon 3000-something CPU. It's run to run some sort of FreeBSD so Nanobsd should be well supported. This week however, we started running some test through the firewall. We're stresstesting Varnish, a http accelerator. The problem is that the pfSense box seems to be the weakest link in the chain. Quickly we saw the state table run full. When we increased the size of the table we run out of CPU quite fast. Load (read using vmstat) jumps up to ~50. Is it probable that this is due to the overhead of state tracking? When you hit the limit of your hardware, you'll run out of CPU. At what point that happens depends on the speed of the CPU, and what NICs you have. The ceiling for a given piece of hardware is packets per second rather than bandwidth, and large scale HTTP load testing can generate a lot of packets. The overhead is in the firewalling. At what throughput levels are you pegging the CPU? One other consideration with any HTTP load testing with stateful firewalls is to be careful with your methodology. Generating large numbers of requests from a single source IP will lead to source port reuse which will be problematic with any stateful firewall (you'll start to see some connections failing) and generally isn't indicative of real-world usage patterns. I suspect given your business, you probably already know that. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
