Express Queue

Advantage Concepts

  Previous topic Next topic  

When a client request such as an SQL command arrives at the server and there is at least one unused worker thread available, that thread will immediately start processing the request. If all worker threads are busy with other operations, the new request is placed in the request queue to be processed by the next available worker thread. Typically, these requests are processed in order of arrival. Beginning with Advantage v10, Express Queue functionality changes this behavior slightly. Requests are still placed in the queue in the order received. However, requests from connections that have a history of short operations are also placed in the express queue.

 

A limited number of worker threads are allowed to take items from the express queue but only when the remaining number of available worker threads drops below that limit. This can allow short operations to be processed in a more timely fashion and not have to wait behind connections that have a history of running long (costly) operations.

 

The type of situation that is helped by the express queue is when there is a mix of application types running against the server. If, for example, the number of applications making costly server requests exceeds the number of configured worker threads, they could, in previous versions of Advantage, limit the number of requests made by other applications. Requests from applications making short requests would be intermingled with the long requests and, effectively, run at the same rate as the more costly requests. With the express queue, a number of worker threads are allowed to process the shorter requests ahead of the longer requests. This can make time-critical applications that have short requests such as interactive user applications operate in a more responsive fashion.

 

The cost prediction for each connection is based on an estimated sliding average of the previous requests. The threshold for being placed on the express queue is recomputed regularly by the server so that it is always based on the current set of connections. Therefore, Advantage automatically adjusts the express queue behavior to conform to the current workload. It is possible to retrieve the current threshold by calling the system procedure sp_mgGetActivityInfo, and individual connections’ estimated costs can be retrieved with sp_mgGetConnectedUsers.

 

It is possible to tune specific connections to always be included or excluded from the express queue. The system procedure sp_SetRequestPriority controls this. Typically, though, it should not be necessary to use sp_SetRequestPriority. Thus, it is unlikely that any changes need to be made to applications in order to benefit from this new functionality.