The first half of the year, a WiFi certification system project was taken over in the 10,000 campus, with client complaints concentrated on early peaks and lunch break hours, accreditation pages were open, text code received after 10 minutes, individual areas directly alerted"Authentication server not available". Everyone dumped the pot at first with insufficient bandwidth for exports, and the problem remains after it expands. We then took the entire certification chain apart to check out the real bottlenecks.
The speed of loading the authentication page determines the user's first impression.
The first page that the user will jump out of after it connects to WiFi in Portal certification is the authentication portal. The speed of loading this page directly determines whether the user will not give up the connection. We found a rather unexpected problem during our screening: the front end resources for the authentication portal.——CSS, JS, background pictures.——All of them are placed on the same server that certified backstage, and no CDN acceleration was done. When thousands of people were at WiFi together at 8:30 a.m., this server had to handle HTTPS certificate consultations, Portal page renderings, and Radius authentication interactions, the CPU was immediately full.
We strip the static resources of the authentication portal off to an independent Nginx inverse node, with only a backstage server and immediate effect. The first screen load time for the certification page is reduced from an average of four seconds to one second, and users are largely unaware of waiting. This is just the first step.
Radius' interactive queue effect is far more severe than expected.
The real headache is the intersectional bottlenecks of the Radius protocol. The standard Radius authentication process is: terminal association AP → AC Launch Access-Request → Radius server processing → returns Access-Access-Reject → AC sends out a strategy. This process is done in dozens of milliseconds of single user settings, and no problems are apparent. But at peak hours in the park, the number of users initiating certification requests can reach hundreds or even thousands in dozens of seconds.
The problem is that most of the Radius services in WiFi certification systems are based on FreeRADIUS' secondary development, which by default is a one-way event driven model and has processing capacity limited to CPU single nuclear properties. When hundreds of Access-Requests come in simultaneously, the request will have to wait in queues. If the previous request is slow because backend database queries are being made——Like checking the user package, checking account balances.——The whole line will be blocked.
The first level is to add a layer of UDP load balance to Radius, which distributes requests to multiple Radius examples in parallel. The second level is to cake data such as user packages and account balances that change less frequently into Redis, where Radius handles requests directly from caches and does not search the database every time. The third level is critical: authentication requests are graded. Normal extension (e.g. users roam from one AP to another) takes fast-tracking, new certification through regular channels, and lots through low priority corridors. This ensures that normal user experiences are not affected by backstage batch operations.
The database connection pool is the invisible dark line.
The last straw that crushes the camel is often a database. During our screening, we found that there were only 20 connections to the database network configurations within WiFi certification system. At peak hours, when Radius was active and Portal pages were available, hundreds of people were running and backstage management interfaces were open for queries, the database connection pool quickly ran out. Once the connection pool was full, all the database-dependent operations became operational.——Authentication, billing, log writing——All queues and other connections, with the system responding times rising exponentially.
Resize the connection pool is just a cure. The solution is to separate reading and writing. We'll run all read-only operations in the authentication process.——Ask if users exist, ask about the package policy, check for password Harshi——Point all towards read-only libraries;all writing operations——Record authentication logs, update final log-in times, write billing statements——Point to the main library. This way, reading and writing is not blocked. The pressure on the connection pool is down by half.
After these changes, we look back at the initial complaints. Not because of the lack of bandwidth for the exports, not because of the WiFi signal, but because of the fact that these performance reefs are hidden in a set of certification links, one by one, and then blow up one by one. So if anyone asks me about WiFi certification systems that are high and issued cardless, my answer is: depending on whether you want to take the certification chain down from head to end.