Mécanismes de file d'attente
What happens if a user joins a Waiting Room before the queue activates?
L'utilisateur peut patienter dans la salle d'attente, mais ne se verra pas attribuer de numéro d'ordre avant l'activation de la file d'attente. Tous les utilisateurs qui se trouvent déjà dans la salle d'attente au moment de l'activation de la file d'attente se verront attribuer un numéro d'ordre aléatoire. Les utilisateurs qui rejoignent la file d'attente par la suite se placeront derrière ces premiers utilisateurs, dans l'ordre où ils ont rejoint la file d'attente.
Why don’t I always see the queue drop by exactly the amount I’ve set?
Plusieurs raisons peuvent expliquer pourquoi la baisse du nombre d'éléments dans une file d'attente ne correspond pas exactement au taux d'entrée que vous avez défini dans CrowdHandler :
- Le quota de domaine est défini pour toutes les files d'attente de votre domaine. Vous pouvez avoir plusieurs files d'attente actives ; dans ce cas, le quota de domaine est réparti entre toutes les files d'attente actives. Dans le cas d'une file d'attente « catch-all », il peut y avoir du trafic en arrière-plan qui est constamment transféré sans que la file d'attente ne se remplisse. Ces transferts sont tout de même pris en compte dans votre quota de domaine, car il s'agit toujours de trafic que votre domaine doit traiter.
- Some users in the queue give up and their session expires. In this case active users are favored for promotion. The increase in transacting users is limited to your domain rate, but you will see the queue drop by a bigger number due to some of the sessions in the waiting room expiring, in addition to your set rate being promoted.
Will the user join any catch-all queue as soon as they exit another queue?
Cela ne va-t-il pas les faire passer deux fois dans la file d'attente ?
When a user is promoted from a queue, they are automatically promoted for any catch-all queues on the same domain. This double promotion is only counted once for all transacting users.
Which queue gets priority?
Les utilisateurs d'une file d'attente « fourre-tout » devront-ils attendre derrière ceux d'une file d'attente spécifique, ou l'inverse ?
Think of queues more like lanes on a freeway. They all have the same capacity, but tailbacks start to build up at the exits where the demand is. So if you have a very busy queue for a specific product, and low levels of background traffic, the waiting room for the catch-all queue will probably not kick in at all. However, if you do see a surprise spike in background traffic, the catch-all waiting room will kick in, and both queues will empty at the same rate. The same is true if you have two or more specific queues running concurrently on the same domain.
Why don’t I always see a perfectly even output flow from simultaneous queues?
Les utilisateurs actifs sont les premiers à quitter la file d'attente. Les places dans la file d'attente sont conservées pour les utilisateurs qui ont été promus, même s'ils se sont déconnectés de la salle d'attente, jusqu'à l'expiration du délai d'attente. Si une file d'attente est active depuis un certain temps, il est probable qu'une proportion plus importante de ces utilisateurs soit inactive. Dans ce cas, une file d'attente plus récente et plus dynamique absorbera une part plus importante du trafic sortant.
Why do I often see a significant drop in the queue 3 minutes after a spike in traffic?
Souvent, un pic de trafic initial est provoqué par des robots « scrapers » ou par des utilisateurs qui recherchent simplement des informations sans intention immédiate d'effectuer une transaction. Ce type d'utilisateur se connecte généralement une seule fois et ne se reconnecte jamais lorsqu'il se retrouve dans une file d'attente. CrowdHandler détecte ces utilisateurs et met fin à leurs sessions afin de laisser la place aux véritables utilisateurs dans la file d'attente.