Sticky connections causes major performance hit?
Our pfSense installation (1.2.3) has a LAN and two WANs. The WAN connections are 50mb/s each and the maximum number of concurrent LAN users is approximately 750.
We experienced issues with websites that do not support IP changes within a session, so we enabled sticky connections and things worked well. When traffic increased we noticed a discrepancy in bandwidth consumption from the previous day (when sticky connections had been turned off). We also started to receive complaints about web site page load errors and slowness. AS a test we turned off sticky connections and these symptoms abated. Total traffic utilization went from 30-40/mbs to 60-75mb/s (a more normal level for our users).
Is this behavior to be expected from pfSense 1.2.3, MultiWAN and Sticky Connections? Does anyone have a better solution for handling websites that have session IP security?
I also note an increase in "user util" and the number of processes on the RRD graphs. If I also do an "uptime" while sticky connections are on the load increases from .30-.40 to .80-1.0. The leads to question this on a performance basis. Some hardware and configuration notes follow. Is it possible we don't have the horsepower?
Intel Pentium D 805 (2.66/533), 2GB DDR 400
CARP/pfSync - Realtek 8101
LAN - Intel PRO/1000 (Intel PWLA8391GTL)
WANs (OPT2 & OPT4 VLAN interfaces) - Intel PRO/1000 (Intel PWLA8391GTL)
The only package we're running is pfflowd.
This wasn't a performance problem, just sticky connections failing. Hopefully it will be fixed in 2.0.
We did the same setup.
two wans and our lan.
We experience the same problem, without sticky connection, Victor cannot play on the Internet.
With sticky connections activated, we experience serious page load errors.
We didn't put yet the system on production (we have 50 lan users who stay on one connection for the moment).
Did some of you guys find a solution ?
We thought trying the pfSense version 2.0.beta.
Thanks for your help.
123 it team.
Sorry, no real solution here. We're just not using sticky connections because it is buggy. I've heard that 2.0 does resolve this but we're not in a position to run it in beta, this is a production environment. For the time being we're just living with the consequences.
The best temporary solution is to make a failover group and assign traffic that needs a static connection to the failover group instead of the round-robbin.