High-commutation bottlenecks in WiFi network billing systems and system layer optimization thinking

A few years ago, a project was evaluated by WiFi, a company operating in the park, whose WiFi network billing system often experienced problems of certification time-over and delays in accounting at peaks. A view of a log showed that the problem was not logical for the system itself, but rather for the performance of the bottom database.——The peak period and the request for certification were more than one, the database was written in queues, with the time of the authentication response jumped from 1,200 milliseconds to two or three seconds or even longer.

WiFi network billing systems have a different feature for co-influence than traditional Web applications. The traditional Web application is requested by users, but WiFi billing scenes are automatically initiated by the equipment.——Users automatically trigger the authentication process when WiFi is connected to them, and when NAS automatically sends billing messages after certification is successful, users switch APs trigger recertification. This means that the number of requests for the system is not the amount of active user-operated but the total amount of all online equipment. Thousands of devices are linked to WiFi over a single time period, several orders of magnitude higher than the number of Web applications of equal user size.

For example, a mall opens at 10:00 a.m., and there may be thousands of devices that try to connect WiFi in half an hour. Each device is certified for two or three times as much as RADIUS (Access-Request/Access-Access-Access-Access-Challenge) and subsequent billings.

Most of the WiFi network billing system is a tool bottled database. The authentication process requires checking user accounts, passwords, check account balances and suite status, reading the database at every step; the writing of billing reports is also high-frequency.

The usual optimisation is several: first, hotspot data are placed in Redis, basic information for users, package information, high frequency readings, and the following certification is loaded from MySQL to Redis at the time of initial authentication, read directly from Redis, with a delay of dozens of milliseconds to within one millisecond. Second, billing is done in bulk processing, not once for every Accounting report, but in memory re-volumeing (e.g. all reports within 50 or 500 milliseconds). Third, reading separation, authentication requests to go into the library, counting to go into the repository without interference.

FreeRADIUS’s default linear configuration is often conservative and needs to be adjusted to actual hardware conditions in the production environment. In addition, RADIUS uses UDP protocols, which do not have a connection concept, so RADIUS services also directly affect high drop-out rates at operating system level for the size of the socket buffer zone and receiving queue length.

If the single-node RADIAUS service is no longer capable of meeting and sending demand, the next step is to load up a RADIAS cluster. Put a LVS or Nginx UDP Stream in front of it a four-storey load balance, with multiple RADIUS nodes attached behind it, each one processing part of the request independently.——NAS sent the request to the load equalizer, which was forwarded to node A. Node A must return to NAS via the load balanced and cannot directly revert to NAS, otherwise NAS would have rejected it as inconsistent with the requested target IP.

The performance monitoring of WiFi's network billing system should cover several key indicators: the number of requests per second for certification (Auth TPS), the processing of reports per second (Accounding TPS), the average authentication response delay, P99 certification response delay, RADIFUS message queue length, and the number of slow database queries. These are your baseline values, normally, and once an indicator deviates from a given percentage, it should trigger alarm alerts.

In terms of capacity planning, it is recommended that the system capacity be designed at least twice the actual peak.——Lunch hours, 8 p.m. to 10 p.m. and weekends are often five to ten times the normal height. If you design capacity on a flat load, the peak period will be problematic. High co-optimal performance is not a one-time task in WiFi network billing systems. The growth of user size, new business functionality online, changes in third-party interfaces will continue to affect systemic performance. It is recommended that baseline performance data be incorporated into daily traffic monitoring, running one round of performance back testing after each version upgrade or configuration change. The sooner the problem is detected, the lower the cost of repair will be less for users."WiFi's too slow to certify."At the time, the window was already more than half-full. Another frequently overlooked point: performance optimization priorities were not evenly distributed. The optimal priority for certification response delays should be highest, since it directly affected user experience; cost writing was lower than internal operating efficiency; and report queries were lowest because it neither affected users nor real-time operations.