The product information says that Portal certifies more than 4,000 times per second, Radius certifies more than 4,000 times a second, and the enterprise-level Portal single-air machine has a maximum number of users of millions. These figures are very strong in the program, but if they are written directly into the contract as acceptance criteria, then the likelihood is much worse. Any performance indicator under the competency boundary rule requires hardware specifications, network bumps, combusts and pressure methods, which cannot be taken out of context. This is not a word game, but because the preconditions for establishing these numbers may have a lot to show off.
The syndication model needs to be clear.
The combination model must be clarified before the performance is discussed. At the same time, 100,000 online users and 4,000 new authentications per second are two completely different things. The former test is session maintenance and online table management, while the latter test is the ability to process certification requests in a short time. A project may have large numbers online at the same time, but requests for accreditation are concentrated on early and late peaks; there may also be few online, but each break-line is likely to trigger a significant recertification.
The pressure method must be included in the acceptance form.
The same system, with different stress measurement methods, can be a lot worse. How the request is sent, whether there are time-times to simulate real users, whether the validation code is overtaken or called, and whether the failure request has been retested, will affect the outcome. So in receiving documents, besides writing indicator values, it is necessary to write down the pressure: how tools, traffic models are designed, how long they are tested, how far they are calculated.
It's not just the amount of throughput that you want to see.
The amount of throughput is not good enough to be experienced. Receiving and inspection depends on at least four categories of indicators: certification success rate, average authentication time-consuming, peak pressure time-consuming, and distribution of failure types. Success rates below expectations usually indicate a chain of instability; average time-consuming decisions about user perceptions; peaks time to decide whether the peak period will fail centrally; and failure type distribution is most valuable, which tells you that failure focuses on overtime, verification failure or system rejection, while different types of failure correspond to an entirely different optimal direction.
The acceptances are meaningful only if they're actually high.
Pressure measurement must run near real toppings. Side and serial deployment, the path of authentication requests is different; there are significant delays between certification platforms and access devices, whether they are in-line or cross-wire; and whether they have passed firewalls or made an address conversion will affect the outcome. The beautiful numbers that come out of simplified environments are often reduced to production. If conditions permit, it is best to use a real device for pressure before cutting, it is not possible to indicate in the receiving document the difference between the test environment and the actual environment, as well as the expected impact on the indicators.
We need to leave the observation tools on the line.
The acceptance passes are not representative of the latter. There is a continuous observation after the system is online, with operational indicators such as daily terminals, monthly life terminals, registered users, fee-based users, continued cost households and end-of-life users, and online users. The value of these data is that when business size increases or user behaviour changes, you can first notice that pressure rises, rather than wait until large areas fail to know.
Correct formulation of indicators when entering into contracts
If the contract or tender response is written, the correct formulation is to bind the indicators and preconditions together. For example, indicate which hardware configuration, which deployment mode, which side model, how many certifications per second are achieved, no less success rates, and no more than an average time. And keep one: the actual indicator is based on field pressure results. This would seem difficult, but for both parties, the first has a well-founded commitment that B does not bear the previously unestablished indicator because of environmental differences.
The extension is pre-counted.
The acceptance indicator is not enough to meet the current size, but also to see an expansion path. After the number of users doubles, do you want equipment to be expanded horizontally or upgrade single-machine configuration? Do you want certification services to be discontinued during the extension process? These questions are raised at the receiving and inspection stage to be more accommodating than they are temporarily managed when expanding. It is proposed that a separate section of capacity planning be included in the receiving and inspection document to describe the volume ceiling for which the current configuration corresponds, what size will increase, how it would expand and how it is expected to affect it so that the subsequent business expansion will not be disrupted.
What do you do when the acceptance is not passed?
When the pressure does not meet the desired target, the first thing is to position the bottleneck on which level instead of immediately adding equipment. The bottleneck may be in the processor ' s own capacity, or in the database, or on the interface between the platform and the access device, all three situations being handled differently. The way it is located is to look at each layer separately, depending on its time-consuming and resource-consumption, and to find the first level to fit. One thing is to pay particular attention to not making indicators appear to meet the standard by adjusting the time-out parameters or relaxing the definition of success rates, simply by hiding the problem and exposing it as it becomes visible.