One of the most feared things for the university's informatization department is campus network every September."It's blown."Thousands of new students gathered their cell phone numbers, activated the campus network account, connected WiFi on the day they were reported.——All these actions occur simultaneously in a few hours. If your campus network WiFi web-based billing system is not prepared for this extreme combination, it is basically certain that there will be large-scale certification timeouts, Portal pages that cannot be opened, and certified users suddenly fall offline. This is not a theoretical risk; it is a real scenario that repeats every year.
The flow patterns of the school year are completely different from normal.
The campus network’s requests for accreditation are usually evenly distributed: at 8:00 a.m., when you get up, drop out at noon, return to the dormitory at night, there is about three to five times the difference between peak and grain values.
But the start of school is different. Newborns usually report for hours between 9 a.m. and 4 p.m., and they report to several of the processes."Authentication trigger point": you get a school card and activate the network account, you have to bind the phone number after loading the school APP, you have to complete the first certification for the dormitory WiFi, and you have to tie the school number in the official school public. Each trigger point corresponds to a wave of authentication requests, and there is no gap between them——Students will take the next step as soon as they have finished their last one.
If your authentication server handles 50 requests per second, the peak may reach 1,000 to 1,500 per second. If the system is designed in normal time, it will be almost inevitable that the certification will take longer.
Where are the performance bottlenecks in the authentication chain?
A complete request for certification is sent through to the end of several stages: wireless AP→Wireless controller (AC)→NATHHELL_AUTH_GATEWAY→RADIUS Server→Backend bill/user database→Operator certification agent (if you dock with the operator). Any performance bottlenecks along this chain lead to a user feeling"Authentication Slow"Or..."Authentication failed"。
The most common bottlenecks are three.
The first is the processing capacity of RADIAUS servers. Most of the RADIUS modules in the system are written by Python or Java, and they can be 200 to 500 per second for one-line processing of RADIAS requests. This level of measure is not enough during the start of school season. One solution is to open up multiple processes/multilines, and the other to separate the RADIAS certification service, which is handled on a dedicated high performance RADIAUS server (e.g. FreeRADIUS), with billing systems that only manage strategy and user management.
The second is the speed of querying a user database. Each authentication check the user database to verify passwords, check account status, and obtain billing policies. If the user data are in MySQL, the response time for queries during authentication will increase significantly after the amount of single-sheet data exceeds 100,000. It is recommended that user tables be separated from writing, that the search go to the main library, and that the user library be written into the operating library. Or simply store high frequency queries at authentication time in Redis, only if the cache is missed.
The third is the delay in responding to operator certification agents. As mentioned earlier, the operator-side authentication link usually jumps through several layers of network and response times fluctuate widely."Synchronize to await operator return result"The operator's slow, and your side will pile up. Consider changing the certification to a non-step mode.——Users are first released (based on local authentication results), and the operator-side synchronisation is done slowly at the back of the station. User experience is not affected by the operator’s delay.
Portal page resistance is often ignored.
When you talk about high-level distribution, attention is focused on the authentication service, but Portal pages are a bottleneck. Portal is a Web application, and when a large number of users open it, the Web server must be able to carry and send access requests. If your Portal page is a single page application with a lot of pictures and external resources, the front end load time will become very long at the start of the school season combined.——The user didn't see it."Authentication timeout"It's..."Pages are going round."And it's as bad as it gets.
Portal pages are designed to be simple: minus. Remove all unnecessary pictures and animations, but only maintain authentication forms. Static resources make CDN caches or local cds. If possible, Portal pages are deployed directly on Authentication Gateway instead of a separate Web server, reducing one network jump. Our experience is that a streamlined Portal page can support 5,000 simultaneous visits per second on single machine Nginx, which is sufficient for most high school start-up seasons.
Pre-pressure is the basic thing.
One of the most critical suggestions is to do a real stress test before school starts. Use tools to simulate the level of authentication requests for the start-up season (i.e., 1,000 certification requests per second lasting 30 minutes) and observe response time and resource utilization at each point in the entire chain of certification.
The pressure is measured with attention to several indicators: whether the certification success rate has been maintained at more than 99 per cent; whether the average response time is within three seconds; whether there are delays in connection or requests for queues? Is the server CPU and memory usage above 80 per cent? If these indicators fail, bottlenecks are identified and optimized on a case-by-case basis.
The pressure is best done twice: first during summer break, when problems are solved; second one week before school starts, to confirm the effects of repairs."Last year's fine. This year, I think."However, the number of students is growing, the type of terminal changes and the operator network environment are also being adjusted. Last year ' s normality does not mean that it is still normal this year.
Emergency plans need to be, but not just for use.
Even when well prepared, there may be unexpected events during the start of school. Common contingency measures include temporary closure of some non-core certifications (e.g. only school accounts are maintained and visitors ' accreditation is temporarily closed), increasing and processing time-out thresholds (preferably more than allowing users to wait for a few seconds without misreporting) and enabling backup authentication links (where the main link is an operator's agent, the back-up link can be local authentication optic).
But these plans have to be written and rehearsed in advance."It's blown."The information department should confirm with the Web-based support team the process and the person responsible for the emergency plan within a week of the start of the school, to ensure that problems are being encountered and the emergency programme is switched over within one minute.
Finally, the performance of the WiFi network system on campus during the start-up season has had a direct impact on the first impressions of thousands of new students. They come to school on their first day and find that WiFi is not connected, and this negative experience spread rapidly in school forums and parent groups.