====== RADIUSdesk Capacity Planning ======
===== Introduction =====
  * One of the questions which often comes up is how much users / devices can RADIUSdesk support.
  * There are not a simple straight forward answer and thus we will break it up in two main sections and discuss it further.
    * **FreeRADIUS**
    * **MESHdesk and APdesk**

===== FreeRADIUS =====
  * The load on FreeRADIUS can be categorized into three categories.
    * **Standard Authentication Requests**.
    * **EAP Authentication Requests**.
    * **Accounting Requests**.
  * To reduce the load on the RADIUS server you can make adjustments to the clients in two places.
    - With EAP you can enable features like **WLAN Roaming**. Consult the vendors documentation how to implement it. This will reduce the number of EAP requests as a user approaches and moves away from a certain Access Point which are using WPA2 Enterprise (EAP).
    - With the Accounting requests one can typically specify if there needs to be Accounting Interval Updates. By limiting the interval to a larger amount of time one can dramatically reduce the Accounting traffic to the RADIUS server.
  * The amount of RADIUS clients does not really impact the server performance, but rather how much traffic the server get from these clients.
  * To go to an extreme to demonstrate the point. One can have 10 000 Dynamic Radius Clients registered but only a few of them have active users. The server will not experience much of a load.
  * On the other hand one can have one Dynamic Radius Client which are using EAP and also Accounting with an Interim Interval of 60 seconds. With 1000 users connected to such a client, the server will definitely be fairly busy.

Next we will be looking at **MESHdesk and APDesk**.

===== MESHdesk and APDesk =====
  * Much of the same principles which applied to FreeRADIUS also apply to **MESHdesk and APDesk**.
  * Both **MESHdesk and APDesk** has a heartbeat system which will periodically sent data to the server.
  * By default it is 60 seconds. One can increase that to dramatically reduce the total traffic sent to the server over time.

===== Going Very Big =====
  * If you are planning to do deployments where there might be 10 000+ active users, you obviously should look at proper hardware and even redundancy on the MySQL database etc.
  * We would advice that you find expertise in those fields since it is not our primary focus.