In last blog (/blogs/2013/06/28/efficient-queuing-but-where/) we discussed about the old and new queuing mechanism in NetScaler and now let us understand how the new implementation works.

The queuing control at Application or vserver layer has to use strict en-queue and de-queue logic such that it controls the unified distribution across all the services and also ensures the protection features work as expected.

En-queue Trigger

Queue it up… looks simple but this is where we need to ensure that queuing is efficient and performance oriented beyond taking care of the functionality… let us look at the use cases:

1)      Resources available on service

  • Let LB happen as normal processing and conn is given to service

2)      Resources are NOT available on service and queue DOES NOT EXIST on vserver

  • Allocate memory for queue at vserver
  • En-queue at the vserver level

3)      Resources are NOT available on service but queue EXIST on vserver

  • En-queue at the vserver level

4)      Queue EXIST on vserver but resources are AVAILABLE

  • En-queue the current connection
  • Trigger de-queue event on head of the queue

De-queue Trigger

Clearing the queue is even simpler as far as capacity exists at end services. Here is quick flow:

1)      New client connection

  • En-queue this connection
  • De-queue existing client from front of the queue

2)      Server triggered de-queue without Persistency

  • If server side connection is free
  • Surge count on server is 0
  • Put the client connection to same server which triggered de-queue

3)      Server triggered de-queue and Persistency

  • In case of persistency we always de-queue matching client
  • Is no matching client is waiting then we pick up highest priority client

4)      Timer based de-queue

  • Every 1 second we will de-queue and resume LB of a client connection

In nutshell this new queuing technology is going to help the end users and also the Application owners in big way… more reasons to get to NetScaler 10.1 release 🙂