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
emeric.jarn...@univ-smb.fr 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