More or less: if you can run pfSense at all, you won't run out of memory for state tables. Captive portal does consume additional memory, but not large amounts. For several hundred users behind a captive portal, I would err on the side if caution and use a system with at least 2GB of RAM, preferably 4GB. The ram requirement depends more on what else you have running inside pfSense than the # of users. One user running bittorrent can potentially create tens of thousands of states, whereas one user browsing the web isn't likely to create more than 10 or 20 at a time (maybe a few hundred if you don't close states aggressively). -Adam
On May 27, 2015 7:39:44 AM CDT, Emeric Jarnier / DSI <[email protected]> wrote: > > Hello everyone, > >I am looking ahead to deploy pfSense for a few hundred of concurrent >users >in a captive portal usage. > >According to hardware requirements and sizing available on the >internet, >it is possible to have some idea of some hardware configuration. >Problem is, we don't have many tips regarding 'states table' usage. >If some of you guys could give us some feedback regarding these aspect, >we >would really appreciate your help! >Anything like a number of states per captive portal user session would >be >great. Il could help us to estimate our maximum number of simultaneous >users with a given amount of memory.. > >I did some tests in a lab and got over 2 000 opened states for a portal > >captive user but it cannot be as good as some real production numbers! > >Thanks for your answers! > >Regards, > >Emeric Jarnier > >_______________________________________________ >pfSense mailing list >https://lists.pfsense.org/mailman/listinfo/list >Support the project with Gold! https://pfsense.org/gold -- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
