Policy and Rule Descriptions
Policies Set in WebQoS
Threshold Policy
The threshold policy is an “internal” measure used to ensure that your system is operating in a reasonable performance range and does not get overloaded. It puts limits on CPU load.
If CPU load gets too high, your server may get into a thrashing state causing few or possibly no requests to be satisfied in a timely fashion. If WebQoS queues begin to grow abnormally, this may signal a problem with your web server or an application/database process that it relies upon.
The threshold policy supported by WebQoS is:
•Ensure CPU is no more than PERCENT % busy
This threshold policy lets you specify the upper threshold of how busy the CPU is. The CLASS request classification information is not required.
You can define five threshold policies for up to five CPU thresholds.
Corrective Actions for SLO and Threshold Policy Violations
Corrective actions are those actions taken to bring an SLO or threshold policy into compliance. These actions are only performed on new sessions. Existing sessions that are already admitted into the system are not affected. The corrective actions supported by WebQoS are:
•Redirect sessions up to NUMBER times for CLASS priority request
This corrective action limits the number of times a session can be redirected. You enter the NUMBER of times for the respective priority request. It is highly recommended that the specific URL all have mirrored sites. You can redirect the session to the URL of a website (for example, http://www.bigcompany.com) which would redirect sessions to this specified location.
If the NUMBER of redirection is met, the next corrective action for this class is executed. If no other corrective action for this class is found, the session is admitted into the system. Therefore, it is highly recommended that every redirection policy has a rejection action of the same class following it in the corrective action list.
124 | Appendix A |
