On 10/17/07, Paul M <[EMAIL PROTECTED]> wrote: > Chris Buechler wrote: > >> The default number of max states is 10 000. I use a dual core > ... > > Roughly 1 KB RAM per state. Conservatively, you should be able to use 1 > > GB RAM solely for states, so you can do about a million easily. > > how does it scale in terms of state look-up? > > I ask because we are using pfsense in front of web farm which provide > content to cellphone/mobiles, so although bandwidth won't be huge, there > will be a lot of concurrent connections.
According to http://kerneltrap.org/node/477 (from 2002, but I don't recall any major changes to the state lookup code) state lookups are an O(log n) function. The most pertinent part of that article for you is: JA: What limitations are there on the maximum number of active states? Daniel Hartmeier: The only limit is the amount of memory. A generic kernel on a machine with 64MB of RAM can handle more than 65000 states, and the limit extends linearly when adding more memory. The cost of state lookups is O(log n), which means it scales even better. I don't know of anyone who has actually reached the limit in production. People with several hundred thousands of concurrent connections can usually afford 512MB of RAM. The bottleneck in most real setups is the packet rate, and often it's not the packet filter code that exhausts the cpu resources but interrupt rates of network interface drivers and other factors. JA: Taking into account the limitations imposed by hardware, what is the maximum packet rate pf can be expected to handle? Daniel Hartmeier: The smallest legal ethernet frame is 84 bytes, which means the maximal rate is 14880 packets per second for 10 Mbps and 148809 pps for 100 Mbps. If the machine can handle those rates with pf disabled (which depends on hardware and network interface driver), just enabling pf with an empty rule set does not impact performance. With increasing rule set and state table size, the impact increases. A rule set with 20-30 rules, which create around 5000 concurrent states, and have to be evaluated only once per connection (which consist of multiple packets), will typically not affect throughput rate. When the rule set gets larger or has to be evaluated for each packet, or when the state table gets very large, packet loss occurs when the CPU is not fast enough. But real traffic consists of larger packets on average, which means packet rates of 16000 pps are common, and handled without loss by pf. --Bill --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
