Overview
The libQueue TrafficScript library allows you to create and manage HTTP sessions on the Traffic Manager, and limit the number of sessions which are allowed through to the backend. With this library we can set a max number of serviceable sessions, and then the vTM will ensure that no more than that number of sessions are allowed through to the backend servers.
The library allows you to name multiple queues if you have multiple applications running through the same vTM, and use counters to keep track of the number of sessions, being created, re-used, and destroyed on the system.
Whenever the max number of users is reached the vTM will start delivering holding pages, which can be configured to include the users position in the queue. Ajax or a meta-rfresh can be used to refresh the users position periodically to keep them appraise of their position.
Please read the comments in the libQueue library for more information on its configuration.
Usage
Once the library has been imported, you will need to call the init() function to initialise the defaults for use. You can then if you wish override any of the configuration parameters as required. The do_req() function is used to determine if the user can be sent through to the application or sent to the Waiting Room.
import libQueue as queue; $config=[]; $houseKeeping=[]; $counters=[]; queue.init($config, $houseKeeping, $counters); # ===================================================================== # == Configuration Overrides for this host $config["poolName"] = "MyApplicationPool"; $config["queueName"] = "MyQueue"; $config["waitingRoomTemplatePage"] = "myApplicationWaitingRoom.html"; $config["waitingRoomTooBusyPage"] = "toobusy.html"; # ===================================================================== $pool = queue.do_req($config,$houseKeeping,$counters); if ($pool == $config["poolName"] ) { pool.use("www.demo.local"); } else { pool.use("WaitingRoom"); }
The waitingRoomTemplatePage will be parsed for template variables whenever it is delivered to a user. This allows you to brand the page, and also include information about the users queue position in the response. The current template variables available for the waiting room page are:
QUEUE_ID (Displays the PID of the vtm Child process managing this user)
SESSION_ID (Displays the Session ID of the current user)
QUEUE_POSITION (The users current position in their queue)
All occurences of the above text will be replaced with their values, when the page is sent to the user.
More Information
The vTM software is designed to scale vertically within in a machine, and so it creates a single threaded child process per core. This library tries to scale in the same manor and so each child process creates and manages its own queue.
Each child is responsible for managing its own queue. This includes putting new user sessions into the queue, and running house keeping task on that queue to expire timedout sessions. When a queue is not empty, the child which owns the queue is also responsible for migrating users out of the queue and into the application.
The library needs to be configured with the number of cores available to the vTM, so that each child process can deQueue a proportianate number of users whenever migration occurs.
Debugging
There is a debug function in the library, which can be set to any number between 0 and 5. However it is recommended that debugging only be enabled during testing, and set to 0 for production use.
User Counters
The User Counters in the configuration can be used to visualise sessions being created, re-used, timed-out, and destroyed, for both the Application Pool and the Queue (Waiting Room). The default counter assignments are:
Session New (a new session has been Created)
Session Update (A users session has been extended)
Session Expire (The housekeeping process has removed an expired session)
Application Sessions (A session is assigned to the application pool)
WaitingRoomSessions (A session which is in the queue)
WaitingRoomExpire (A user in the queue has timed out)
WaitingRoomMigrated (A session has migrated from the queue to the application)
SessionComplete (A user hit an exit point and the session was deleted)
Timeouts
There a three configuration parameters for timeouts. InitialTimeout is given to all new sessions and is there to prevent automated clients from using up real sessions. Once a session has been reused, then we switch to the standard timeout, either the sessionTimeout or the WaitingRoomTimeout depending on where the user was assigned.
Application and WaitingRoom sizes
The script needs to be given the max number of application sessions allowed in the sessionLimit config value. when this limit is reached users will be sent to the WaitingRoom (queue). There is also a waitingRoomLimit, which when exceeded will cause the user to simply be given WaitingRoomTooBusy page.
View full article
