The campus network Authentication & Billing system performance indicators, which are all very bright numbers written by manufacturers in the programme books——"Single-line support millions of users""Certification over 4,000 times per second""99.99 per cent availability of systems"But the numbers are not real, they're not just documents. There is only one way to test performance.Run the pressure test as close to the real scene as possible.But this..."As close as possible to the real scene."It is very difficult to do this in itself, because many projects have completed stress tests and are being hit at peaks after they have been online, because the test scene and the real environment are far from being the same.
The most typical mistake is thatWe'll only use a single scene for stress testing.. For example, 10,000 users are estimated to be running Portal authentication simultaneously in five minutes.——The system is holding up. The manufacturer says,"We're fine with 10,000."The pressure pattern in the real environment is not the same. The load peaks for late peaks are stacked: students do Portal window authentication, certified users generate online traffic (which generates billing data writing), students fill (payback triggers a package opening) and AC sends NATSHELL_SEAMLES_AUTH requests to the authentication server. These four loads are superimposed. If you measure one of these scenes, the performance data obtained is seriously distorted.
The correct pressure test should be.Mixed Load TestTest scripts require simultaneous simulation of four parallel scenarios: Portal certification requests (memulation of the peak period for new entrants), continuous online flow of certified users (mocking of daily late peaks), charging and package changes (mimulation of initial contribution peaks), Seamless Authentication request (memotional student walk-through). The simultaneous distribution ratio of four scenarios is set by reference to school history data——For example, data from a school show that the percentage of Portal certifications at late peaks is about 15 per cent, online flows are about 60 per cent, Seamless Authentication is about 20 per cent and the charge operation is about 5 per cent, so that the combined load is constructed in this ratio.
The second test blind area is...Performance decay at long-term sustained loadMany stress tests run for 10 minutes or half an hour, and when the system is not up, they end. But in practice, NATSHEL_AUTH_BILLING is a long-term, ongoing system that may start to lose performance after hours or even days of running around. So pressure testing takes at least one round of long durability tests if there are RAM leaks, database connections run out, log files swelling.——It is recommended that a combined load of at least eight consecutive hours be recorded every half hour for key indicators (certification response time, CPU usage, memory usage, database connection) and to see if there are any apparent performance decline trends.
The third key test point is...The ability to downgrade in a malfunction scenario.The real environment is a failure that will happen.——The database's main repository is down, the RADIUS service has been dead, network links are out, and the engine room is out of power. Can the system guarantee at least basic availability of certification services in these exceptional cases? For example, when the database's main library is off-the-shelf, it automatically changes to a reserve, uses local certifier for validation when RADIUS responds over time, saves logs until they are restored to local disks, etc. If pressure tests do not work each time, then the whole web is disrupted.
The performance test under the dialysis model has a unique difficulty:Operator Bras response time is uncontrollableThe authentication process involves a link in which the dial-up gateway initiates a PPOE dial-up request to the operator Bras, whose response time depends on the operator's network status and load level. Your laboratory uses test environments to measure an average of 0.5 seconds for dial-up response times, and BRAS, the first night peak operator on the line, doubles the dial-up response time because of the full web load.——Users may think authentication is stuck. The performance test must include BRAS response delay as a variable parameter, testing system performance in the normal (0.5 seconds), higher (1-2 seconds) and extreme (3 seconds or more).
Finally, a test dimension that is easily ignored:Impact of Portal page size and load speed on authentication success rateSome schools are concerned about the beauty of Portal pages, which have been stacked with high-cleaning rounds, CSS animations and JavaScript frameworks, resulting in a total Portal page volume exceeding 5MB. In a student dormitory with poor WiFi signals or higher AP load, this page may take 10 seconds to complete. Many students think that certification failed and cut out before they loaded it. The impact of the portal page on certification success rates, especially in low signal environments, should be specifically validated at the testing stage.——Simulates the loading of Portal pages under different bandwidth and delay using a network speed limit tool to observe changes in the certification completion rate.
High-commence support is not measured in essence."What kind of loads are the systems going to hang up?"- It's a test."Is the system able to provide a steady and qualified user experience with a combination of real scenes?". The difference between the two is a complete test strategy——Mixed load, long-duration, downgrade, external dependency delay, end-of-pipe weak network environment——And there's one thing missing, and the test is all blind. I'd rather spend another week putting it back together than just be on the line and then call the engine room at night to make a call for expansion.