HP WebQoS Administration Guide

Policy and Rule Descriptions
Policies Set in WebQoS
Appendix A124
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.