AppQoE is a combination of different features on NetScaler—more precisely, HTTPDoS, priority queuing, and SureConnect.

This feature allows us to prioritize traffic based upon different parameters—for instance, where the endpoint is coming from or what kind of endpoint is connecting with the use of expressions. So, for instance, let's say we have an e-commerce website that serves both mobile and desktop users. From experience, we see that desktop devices are more likely to buy something from the site than mobile devices. In that case, if the e-commerce site reaches its maximum threshold or bandwidth, we need to prioritize the traffic and then we want desktop users to get access before mobile users.

To configure AppQoE, we need to define a policy that contains an expression and an action. For instance, this might be an expression containing Android devices:

HTTP.REQ.HEADER("User-Agent").CONTAINS("Android")

That will then have an action attached to it; the action might be what to do with the traffic that matches the expression. This might for instance be to prioritize the traffic, or to display a custom wait page, and so on.

In order to set up AppQoE, we first need to enable the feature either using CLI:

Enable feature appqoe

Or using the management interface, by going into AppExpert | AppQoE, right-clicking and choosing Enable feature.

Then we start by creating an action, by going into the Actions pane and clicking Add.

So let's create an action that will apply to Android devices.

Here there are some actions that can be set:

Action Type defines what action to take when the threshold is reached. There are three types of action we can take. Alternative Content Service (ACS) can be used to redirect requests to another vServer on the NetScaler. For instance, the following screenshot shows an action that will allow NetScaler to serve alternate content, using a custom path, and that will be displayed only if it matches the thresholds, which can either be based upon max connections or delay:

We also have the NS option under Action Type; this allows us to, for instance, display a custom HTML page to end users trying to connect to the vServer. In order to choose a custom HTML page, we must first upload one to the NetScaler under AppExpert | AppQoE | HTML Page Imports and by choosing Add.

We also have the option to not set an action type; this will not allow NetScaler to display any custom content and any connections that are over the threshold will be placed in the lowest priority queue.

Priority defines what priority the traffic should have. There are four values to choose from here: HIGH, MEDIUM, LOW, LOWEST. Traffic will always be processed in that order.

As an example we could have a policy aimed at mobile users, where we have defined all mobile traffic with the priority set to MEDIUM by default, and another policy with priority set to HIGH for desktop users. This would mean that all desktop user traffic would be processed first and mobile traffic would be processed afterwards.

Policy Queue Depth is a value we define on how many connections fall within this policy. Subsequent connections are assigned to the LOWEST priority rights.

Queue Depth is a value that defines how many connections fall within this policy on this particular priority; subsequent connections are assigned to the LOWEST priority rights.

Maximum Connections defines how many concurrent connections can be active before NetScaler triggers an action; likewise, delay is defined in microseconds before NetScaler triggers an action.

Lastly we have DOS Action, which is in essence the HTTPDoS feature; this feature will be covered in much greater detail. In order to define a HTTPDoS action within AppQoE, we just have to define an expression that might be filtering on an HTTP user agent and define an action type that can be SimpleResponse and HICresponse.

It is important to note that we do not define a value for when the DOS action will trigger; this is done globally for AppQoE, and can be configured under AppExpert | AppQoE | Configure AppQoE parameters | DOS Attack threshold. Here we can define the average number of client connections that can queue up before the DOS action triggers.

After we have created an action, we have to bind it to a policy. Policies need to contain an expression that can be using HTTP user agents, IP source, and so on.

After we have created the policy we need to bind it to a vServer. This can be done by going into a particular vServer, Policies | Choose Policy | AppQoE, then binding the policy that we created.

Stat appqoe policy policyname