Comment l'utilisation de notre file d'attente en ligne permet d'éviter le plantage d'un site et les plantages de sites web - combien d'utilisateurs simultanés un serveur web peut-il gérer ?

Pourquoi utiliser une salle d'attente virtuelle basée sur les taux ?

Basé sur les taux ou sur le principe du "one-out, one-in" ? Nous pesons le pour et le contre.

Nous n'avons pas trouvé d'avantages à l'approche "one-out, one-in". En résumé, le problème de cette approche est que lorsque les utilisateurs sont des visiteurs de sites de commerce électronique, le serveur web ne sait pas combien d'utilisateurs simultanés il a à un moment donné. C'est un obstacle. Voici pourquoi.

Plus loin dans cet article, nous vous expliquons également comment utiliser une chambre virtuelle basée sur le taux pour protéger votre site également.



La salle d'attente virtuelle la mieux notée sur G2
G2 est le site d'évaluation de SaaS le plus visité au monde.

Ce que nos clients disent de Queue-Fair


test de charge demandes http combien de demandes un serveur web peut-il traiter sans ressources supplémentaires ?

Combien d'utilisateurs simultanés un serveur web peut-il gérer ?

Si vous connaissez le nombre d'utilisateurs simultanés traités par un serveur Web, ainsi que le temps moyen de transaction ou la durée de la visite, de la première page de votre flux de transactions à la page de confirmation de la commande, vous pouvez convertir ces données en taux de file d'attente à l'aide de la loi de Little en divisant le nombre d'utilisateurs par la durée, comme suit

Taux de file d'attente = Utilisateurs simultanés / Temps de transaction

Quelle est la précision d'un système de file d'attente basé sur le taux ?

Queue-Fair enverra des visiteurs sur votre site Web au rythme que vous aurez spécifié - nous disposons de l'IA de file d'attente de loin la plus précise du marché pour garantir que le nombre de visiteurs que vous souhaitez obtenir chaque minute est le nombre de visiteurs que vous obtenez chaque minute, en tenant compte automatiquement des personnes qui ne sont pas présentes lorsque leur tour est appelé, ainsi que des personnes qui reviennent tard.

Comment cela se traduit-il en nombre d'utilisateurs simultanés ? Bien sûr, tous les visiteurs qui accèdent à votre site ne mettront pas exactement le même temps moyen pour effectuer leur transaction, mais vous obtiendrez un nombre très stable d'utilisateurs simultanés avec Queue-Fair, en raison de la loi des grands nombres.

Par exemple, disons que vous avez un taux d'attente de 100 visiteurs par minute. Nous enverrons 100 visiteurs sur votre site chaque minute, en un flux constant - c'est ce que nous faisons, et nous le faisons remarquablement bien. Disons également que les internautes utilisent votre site Web pendant une moyenne de cinq minutes, 70 % d'entre eux mettant entre 4 et 6 minutes entre le moment où ils passent dans la file d'attente et le moment où ils effectuent leur dernière demande de page (qu'ils effectuent ou non une transaction). Cela représente un écart-type d'une minute de part et d'autre de la moyenne. Statistiquement parlant, cela signifie que pour chaque visiteur qui met cinq minutes et demie, il y en aura un autre qui mettra quatre minutes et demie, et ces variations dans la durée des visites individuelles sur plusieurs sessions ont donc tendance à s'annuler lorsque vous en comptez un grand nombre. Selon la loi des grands nombres, cette annulation devient de plus en plus exacte à mesure que le nombre de personnes concernées augmente.

système d'exploitation nombre maximal de ressources du serveur web
calcul du chiffre moyen pour les utilisateurs simultanés avec intervalle de confiance

A quel point, exactement ? On peut s'en rendre compte avec un peu de statistiques. La taille de l'échantillon est de 5 * 100 = 500, ce qui est le grand nombre impliqué ici. C'est le nombre de personnes que vous comptez. Cela signifie que l'erreur standard dans la moyenne pour le temps de transaction est de 1 (l'écart type, 1 minute) divisé par la racine carrée de la taille de l'échantillon (donc la racine carrée de 500) selon la formule statistique de l'erreur standard dans la moyenne, ce qui donne une erreur standard dans la moyenne pour le temps de transaction de 0,044 minute, ou juste 2,7 secondes, soit moins de 1 %.

Cela signifie qu'avec un taux de file d'attente de 100 et un temps de transaction de 5 minutes, à une minute près, pour chaque visiteur, vous devriez vous attendre à ce qu'il y ait entre 495 et 505 utilisateurs simultanés sur votre site pendant environ 70 % du temps.

Mais ces calculs sont-ils exacts ? Il y a quelques subtilités ici - par exemple, la taille de l'échantillon que nous avons joyeusement quadrillé n'est pas toujours exactement 500 à chaque fois que les utilisateurs simultanés sont comptés (c'est-à-dire à tout moment donné), et aussi une distribution normale (gaussienne) peut donner des temps de transaction négatifs qui ne se produisent pas dans la vie réelle. Nous utilisons donc un simulateur visiteur par visiteur, seconde par seconde, afin d'effectuer des mesures pour vérifier ce type de calculs, et cela nous indique qu'avec les chiffres ci-dessus, vous devez vous attendre à recevoir entre 493 et 507 visiteurs dans 70 % des cas. La mesure des données nous indique également que votre site aura 500 ± 15 utilisateurs simultanés au moins 95 % du temps.

C'est probablement plus stable que la précision avec laquelle votre serveur Web peut mesurer le nombre de personnes utilisant votre site ! Mieux encore, ce qui est vraiment intéressant ici, c'est que même si vous n'avez aucune idée du temps moyen de transaction ou de l'écart-type de vos visiteurs, ces quantités mathématiques existent, que vous les connaissiez ou non, et vous obtiendrez de toute façon une charge stable.

Le résultat est que Queue-Fair fournira le nombre de visiteurs par minute que vous souhaitez avec une précision quasi parfaite, ce qui se traduit par un nombre très stable d'utilisateurs simultanés sur votre site et une charge stable du serveur web sur laquelle vous avez un contrôle total.

Hourra !


servers capacity can be exceeced with inaccurate queues Et maintenant, un avertissement. Il convient de noter que la stabilité du nombre d'utilisateurs simultanés sur votre site - et donc la stabilité de la charge de votre serveur - dépend de manière critique de la précision avec laquelle votre fournisseur de salle d'attente virtuelle vous envoie le nombre de visiteurs que vous souhaitez chaque minute, et il s'agit donc d'un facteur clé lorsque vous choisissez une plateforme de salle d'attente virtuelle. Parce que nous fournissons la Salle d'attente virtuelle la plus précise au monde, personne n'arrête l'inondation de vos serveurs mieux que Queue-Fair.

Un moyen simple de calculer le taux de file d'attente

Que faire si vous ne savez pas combien d'utilisateurs simultanés un serveur peut gérer, ou le temps de transaction ? Vous pouvez examiner la page qui est susceptible d'être votre goulot d'étranglement - généralement celle qui résulte d'un clic sur un bouton "Acheter maintenant". Utilisez Google Analytics pour connaître le nombre mensuel de visiteurs uniques de cette page, ou comptez vos commandes mensuelles. Divisez ce chiffre par 30 * 24 * 60 = 43 200, soit le nombre de minutes que compte un mois (approximativement). C'est votre moyenne de visiteurs par minute sur l'ensemble du mois. Multipliez ce chiffre par trois. C'est le nombre moyen de visiteurs par minute pendant les heures de bureau (environ). Doublez ce chiffre. C'est probablement un chiffre sûr pour le taux de file d'attente à utiliser.

Par exemple, disons que vous traitez 100 000 commandes par mois, soit 100 000 clics sur le bouton "Acheter maintenant". Cela représente 100 000 / 43 200 = 2,31 commandes par minute. On peut s'attendre à ce que la plupart de ces commandes soient passées pendant la journée et que vos serveurs soient plus silencieux la nuit. Multipliez ce chiffre par 3 et vous obtiendrez 7 commandes par minute, ce qui constitue une estimation approximative de l'activité de votre serveur pendant les heures de bureau. Si le chiffre obtenu est inférieur à 50 : il y aura des pics et des creux dans la demande, donc si votre serveur n' est pas sensiblement lent aux heures de pointe, multipliez ce chiffre par 2 pour obtenir 14 utilisateurs actifs par minute. Si le chiffre est supérieur à 50 : les pics et les creux d'une minute à l'autre seront moins importants en comparaison, et il n'est pas prudent de doubler ce chiffre. Le chiffre que vous obtenez est probablement un chiffre sûr pour le taux de mise en file d'attente pour commencer et correspond au nombre de demandes par seconde que vous pouvez gérer en toute sécurité ; vous pouvez toujours l'augmenter si vous trouvez que vos systèmes sont toujours réactifs pour les performances des utilisateurs finaux à ce taux.

calcul des niveaux maximums d'utilisateurs actifs pour votre application web

Si vos commandes sont horodatées, vous pouvez aussi regarder le nombre maximum de commandes que vous avez prises en une seule minute au cours du dernier mois - mais faites attention car vous ne saurez pas combien de commandes vous avez pu abandonner pendant cette minute en raison du ralentissement de vos serveurs, réduisez donc ce chiffre de 20%.

La suite de cet article présente d'autres façons de calculer le taux de file d'attente.

confusion sur les utilisateurs simultanés les connexions simultanées les sessions simultanées et la durée moyenne des sessions

Erreur #1: Utilisateurs simultanés vs Requêtes simultanées vs Connexions simultanées vs Sessions simultanées

Il convient de souligner qu'il existe au moins deux définitions de l'expression "utilisateurs simultanés" dans l'usage courant.

Nous utilisons la définition suivante : "le nombre de personnes engagées dans un flux de transactions à un moment donné". C'est le chiffre clé que vous devez connaître pour définir le taux de file d'attente. C'est le nombre d'utilisateurs qui consultent votre site en ce moment. Le nombre de sessions simultanées est généralement un peu plus élevé que le nombre de connexions simultanées ou d'utilisateurs simultanés, car certaines des sessions sont en train de se terminer, ce qui augmente la durée moyenne de la session.

Comparez cela au nombre de requêtes simultanées, qui correspond au nombre de requêtes HTTP traitées par votre serveur Web à un moment donné. Il est très déroutant de constater que beaucoup de techniciens parlent du nombre de requêtes simultanées lorsqu'ils disent le nombre d'utilisateurs simultanés.

Ensuite, il y a les connexions simultanées (ou connexions TCP simultanées au même port de serveur sur votre carte d'interface réseau), qui correspondent au nombre de sockets TCP/IP ouverts sur le port de votre serveur ou service dorsal à un moment donné. Lors des requêtes de pages, les navigateurs laissent par défaut la connexion ouverte au cas où d'autres requêtes seraient faites par la page, ou si l'utilisateur passe à une autre page. Cela réduit le nombre de demandes d'ouverture de nouvelles connexions TCP/IP par seconde, ce qui rend le processus du serveur plus efficace. Les délais d'attente pour ces connexions simultanées varient selon le navigateur, de 60 secondes à jamais. Votre serveur peut également fermer automatiquement les connexions après une période d'inactivité. Sur les serveurs Web Linux, vous pouvez obtenir le nombre de connexions simultanées au même port du serveur avec cette commande :

netstat -aenp | grep ":80 \|:443 " | wc -l

que vous pouvez essayer si vous êtes curieux. Encore une fois, certaines personnes appellent cela "Utilisateurs simultanés", alors qu'il s'agit en réalité de connexions simultanées.

En effet, si vous demandez à votre fournisseur d'hébergement de vous indiquer le nombre maximal d'utilisateurs simultanés que votre serveur Web peut gérer (c'est-à-dire le trafic de pointe), il vous donnera probablement un chiffre pour les sessions simultanées, les demandes simultanées ou les connexions simultanées, pour la simple raison qu'il ne connaît pas le temps moyen de votre transaction, le nombre de pages dans votre flux de transactions ou toute autre information qui lui permettrait de vous dire combien d'utilisateurs simultanés votre serveur Web gère. Tous ces chiffres ont des valeurs différentes.

Si vous demandez à votre fournisseur d'hébergement ou à votre équipe technique des informations sur les niveaux de trafic maximum, il est très important que vous précisiez s'il s'agit d'utilisateurs simultanés, de sessions simultanées, de demandes simultanées ou de connexions simultanées.

Si vous vous trompez, vous risquez de faire échouer votre site web !

Voici pourquoi. Chaque page est une demande HTTP unique, mais toutes les images, tous les scripts et tous les autres fichiers provenant de votre application web que le navigateur utilise pour afficher la page sont également des demandes HTTP.

Imaginons que votre équipe technique vous dise que le serveur prend en charge 500 utilisateurs simultanés, alors qu'il s'agit en fait de 500 demandes simultanées. Avec votre temps de transaction de 5 minutes, vous utilisez la formule ci-dessus et supposez que votre site peut supporter 100 visiteurs par minute.

C'est possible ? Non.

Au fur et à mesure que les personnes passent par le flux de transactions, elles n'effectuent des requêtes auprès de vos serveurs que pendant le chargement de chaque page. Cela affecte le volume de trafic par seconde ou le nombre d'utilisateurs actifs que votre serveur peut gérer. Sur les cinq minutes que dure une transaction, cela ne représente que quelques secondes pour un utilisateur moyen. Vous pourriez donc penser que 500 requêtes simultanées signifient que vous pouvez gérer beaucoup plus d'utilisateurs simultanés, mais vous pourriez bien vous tromper. Vous comprenez maintenant pourquoi il est si compliqué de comprendre la capacité de votre site Web en termes de trafic ou de nombre total d'utilisateurs actifs ?

protégez d'abord les ressources de votre serveur lorsque vous calculez le nombre de requêtes que vos pages web peuvent recevoir afin d'offrir une bonne expérience à chaque utilisateur.

Conversion des demandes simultanées en utilisateurs simultanés

Pour calculer le nombre maximum d'utilisateurs simultanés à partir du nombre total maximum de demandes simultanées, vous devez également connaître les éléments suivants

  1. Le nombre de pages dans votre flux de transactions
  2. Le temps moyen de transaction des visiteurs entre la première et la dernière page de votre flux.
  3. Combien de requêtes composent chaque page, en moyenne ?
  4. Le temps moyen que prend votre serveur pour traiter une seule requête HTTP.

Vous connaissez probablement déjà les points 1) et 2) - dans notre exemple, il s'agit de 6 pages et de 5 minutes. Vous pouvez facilement compter les pages que vous voyez lorsque vous effectuez une transaction. Si vous ne connaissez pas la durée moyenne d'une transaction, Google Analytics peut vous le dire, ou vous pouvez consulter les journaux de votre serveur Web.

Pour les points 3) et 4), le navigateur Firefox peut vous aider. Faites un clic droit sur une page de votre site, choisissez Inspecter l'élément et l'onglet Réseau. Appuyez ensuite sur CTRL-SHIFT-R pour rafraîchir complètement la page. Vous verrez les temps de chargement du réseau pour chaque élément de la page dans la liste. Assurez-vous que vous pouvez voir les tailles de transfert dans la colonne Transféré, car sinon les fichiers peuvent être servis à partir d'un cache, ce qui peut perturber vos calculs. Il se peut que certains scripts et d'autres ressources proviennent de serveurs autres que celui de votre site. Vous pouvez donc taper le nom de domaine de votre site dans le champ de filtre situé à gauche. Pour voir la colonne Durée, cliquez avec le bouton droit de la souris sur n'importe quel en-tête de colonne et sélectionnez Timings -> Durée dans le menu contextuel. Votre écran devrait ressembler à ceci :

google traite un nginx correctement configuré avec google analytics pour le téléchargement de photos

L'onglet Réseau de Firefox pour cette page, montrant la durée et le nombre de requêtes provenant de queue-fair.com

Les fichiers utilisés pour l'affichage de vos pages peuvent provenir de plusieurs sites différents. Vous pouvez donc utiliser le filtre en haut à gauche pour n'afficher que ceux de votre site, mais uniquement si vous êtes sûr que les fichiers des autres sites ne sont pas à l'origine de la lenteur du chargement des pages ou ne font pas partie de votre goulot d'étranglement.

Firefox compte les demandes pour vous dans le coin inférieur gauche de l'écran, et affiche 36 demandes HTTP pour cette seule page.

Vous devez le faire pour chaque page de votre flux de transactions - comptez le total et divisez-le par le nombre de pages pour trouver le nombre moyen de requêtes HTTP pour chaque page, numéro 3) dans notre liste. Vous pouvez maintenant comprendre pourquoi le nombre de requêtes enfant pour chaque page HTML est un facteur si important pour le volume de trafic que votre serveur Web peut gérer.

Pour le point 4), vous devez regarder la colonne Durée et trouver la moyenne de toutes les requêtes HTTP pour toutes vos pages. Si vous n'êtes pas sûr, partez du principe qu'il s'agit d'une demi-seconde - il y a de toute façon beaucoup d'incertitude à ce sujet (voir ci-dessous).

faire des calculs pour déterminer le nombre de sessions simultanées, le nombre d'utilisateurs et le nombre de requêtes par seconde sur votre application web, qu'il s'agisse d'un serveur unique ou d'un contenu statique.

Faire le calcul

Donnons quelques exemples chiffrés. Nous avons déjà dit qu'il y a six pages dynamiques dans le flux de traitement du serveur de l'exemple, ce qui correspond à 1), et que le temps de transaction moyen est de cinq minutes, ce qui correspond à 2). Supposons 36 requêtes HTTP par page pour 3), et une demi-seconde pour le temps de traitement du serveur pour chaque requête HTTP, soit 4).

Avec ces chiffres, un serveur qui peut gérer 500 demandes simultanées peut gérer 500 / (0,5 seconde) = 1000 demandes HTTP par seconde, soit 60 000 demandes HTTP par minute, lorsqu'il est complètement saturé.

Pendant les cinq minutes de la transaction, il peut traiter 5 * 60 000 = 300 000 demandes HTTP. C'est beaucoup, non ?

Mais, pour chaque visiteur, il y a six pages avec une moyenne de 36 requêtes HTTP chacune, ce qui fait 6 * 36 = 216 requêtes.

Ainsi, la capacité de 300 000 demandes HTTP peut en théorie gérer 300 000 / 216 = 1 389 utilisateurs simultanés.

Erreur #2: Les serveurs Web ralentissent avec la charge

Hé, c'est génial ! Nous pensions que nous ne pouvions avoir qu'un taux d'attente de 100, mais 1 389 / 5 minutes = 278 visiteurs par minute, donc nous pouvons avoir un taux d'attente plus élevé !

Eh bien, probablement pas. D'une part, vos visiteurs ne vont pas envoyer des requêtes à intervalles d'une demi-seconde exactement, comme le suppose le calcul ci-dessus. Plus important encore, vous aurez mesuré vos données d'entrée lorsque le site n'est pas occupé. Les déchets entrent, les déchets sortent.

Lorsque le site est occupé, le serveur prend plus de temps pour traiter les requêtes - vous l'aurez remarqué sur d'autres sites lorsque les choses sont occupées, que vous attendez plus longtemps pour les pages. Cela augmente le temps moyen que prend votre serveur pour traiter une seule requête HTTP (4), ce qui diminue le débit maximal. Prenez donc les 278 visiteurs par minute et divisez-les par deux. Puis divisez-le à nouveau par deux. Il est probablement réaliste de penser que vous avez environ 70 nouveaux visiteurs par minute à charge maximale.

plus la charge de votre trafic est importante, plus les machines sont lentes.

Parmi les autres facteurs de confusion, citons la mise en cache, qui signifie que les navigateurs de vos visiteurs n'ont pas besoin d'effectuer chaque requête pour chaque page - le serveur a donc besoin de moins de ressources et peut augmenter le nombre de nouveaux visiteurs par minute que votre serveur peut gérer. Les équilibreurs de charge qui répartissent la charge sur plusieurs serveurs, et le fait de servir du contenu statique plutôt que des pages dynamiques peuvent également accélérer le processus de votre serveur, car chaque serveur nécessite moins de ressources.

Vous constaterez également que toutes les pages ne prennent pas le même temps, car certaines nécessitent moins de ressources que d'autres pour être produites et servies. Les recherches dans les bases de données, les requêtes de recherche et les mises à jour sont les plus longues. Vous aurez donc un goulot d'étranglement quelque part dans votre processus où les gens s'entassent, attendant que les détails de la carte de crédit soient traités et les commandes stockées, ou attendant que la disponibilité soit vérifiée. Chaque flux de transaction a une étape la plus lente, il y a donc toujours un goulot d'étranglement quelque part, et il y a toujours une réponse de valeur maximale à la question de savoir combien d'utilisateurs simultanés un serveur web peut gérer - et il peut y avoir plusieurs limites impliquées. Dans ce cas, vous devez définir votre taux de file d'attente suffisamment bas pour vous assurer que votre serveur dispose d'une capacité de temps cpu suffisante pour traiter suffisamment de personnes simultanément à l'étape la plus lente de votre processus, afin que les personnes ne s'y entassent pas. Sinon, votre serveur web peut littéralement s'arrêter.

incertain de la manière d'estimer la capacité des serveurs de ressources pour chaque utilisateur unique

Alors, qu'est-ce que je fais ?

D'après notre expérience, lors de la première vente, tout le monde surestime la capacité de ses serveurs à faire face à de gros volumes de trafic.

Tout le monde.

La détermination précise de la durée moyenne d'une session et des performances de l'utilisateur final en cas de trafic lent ou intense n'est pas à la portée de tous. La meilleure chose à faire est d'effectuer un test de charge adéquat, avec de "faux" clients qui effectuent le processus de commande pendant le test de charge, exactement comme ils le feraient dans la vie réelle, en effectuant les mêmes requêtes HTTP dans le même ordre, avec les mêmes temps d'attente entre les pages pendant le test de charge que dans la vie réelle, et de garder un œil sur la charge de votre processeur, le débit des E/S et les temps de réponse pendant que vous augmentez le nombre de visiteurs virtuels. Vous pouvez utiliser Apache JMeter pour cela (nous aimons aussi K6 pour les charges plus légères ou les machines plus lentes), mais quel que soit l'outil que vous utilisez, il est long et délicat de reproduire le comportement de chaque utilisateur de la bonne manière (surtout avec les complexités de la mise en cache). Même dans ce cas, prenez votre nombre maximum et divisez-le par deux.

En l'absence de cela, il faut pécher par excès de prudence.

Vous pouvez facilement modifier le taux de file d'attente pour n'importe quelle file d'attente Queue-Fair à tout moment en utilisant le portail Queue-Fair. Commencez par 10 visiteurs par minute, ou votre taux de transaction un jour plus normal, voyez comment cela se passe pendant un petit moment après la mise en vente de vos billets, et si tout semble bien, que la charge de votre processeur est faible, que votre base de données sql est bonne et (surtout) que vos pages sont réactives lorsque vous appuyez sur CTRL-SHIFT-R, doublez-la, attendez un peu, et répétez. Vous trouverez bientôt le taux réel dont vous avez besoin pendant cet "équilibrage de la charge" (vous voyez ce que nous avons fait là ?), et n'oubliez pas que, du point de vue de l'expérience client, il est bon d'augmenter le taux de la file d'attente car cela entraîne une réduction des attentes estimées par vos clients dans la file d'attente, et tout le monde est heureux de voir un temps de réponse offrant une attente estimée plus courte.

Ce qu'il faut éviter, c'est de fixer le taux de file d'attente à un niveau trop élevé, puis de devoir le réduire, car cela a) signifie que les utilisateurs du site sont confrontés à des chargements de pages lents et b) entraîne une augmentation des temps d'attente estimés. Toutes les personnes dans votre file d'attente vont soupirer !

Erreur #3: Augmenter le taux trop rapidement après l'ouverture d'une file d'attente

N'oubliez pas qu'il y aura un goulot d'étranglement quelque part dans votre processus de commande - chaque transaction a une étape la plus lente - et que plusieurs sessions s'y accumuleront. Ce que vous ne voulez pas faire, c'est arriver une minute après le début de votre vente de billets, constater que la charge du processeur de votre serveur est bien inférieure à son maximum, et augmenter le taux. Vos visiteurs ne sont probablement pas allés jusqu'au bouton "Acheter maintenant". Vous devez attendre que votre base de données SQL signale les nouvelles commandes à un rythme identique ou similaire à celui de votre taux de file d'attente et effectuer vos mesures et vos tests de réactivité à ce moment-là. N'oubliez pas qu'à chaque fois que vous augmentez le taux, il faut le même temps pour que les visiteurs supplémentaires atteignent votre goulot d'étranglement. Vous ne pourrez donc évaluer avec précision les performances de votre serveur au nouveau taux qu'une fois ce temps écoulé.

ralentir la décision de consommer les ressources du serveur
snap des serveurs lorsque la capacité des serveurs est dépassée

Erreur #4: Serrer vos serveurs

Nous avons déjà vu qu'il est préférable d'augmenter progressivement le taux de file d'attente une fois que la file d'attente est ouverte. Vous êtes probablement conscient que vos serveurs ont une limite qui ne peut pas être dépassée sans que le système se bloque et vous savez peut-être même quelle est cette limite - mais ce que vous ne savez peut-être pas, c'est que lorsque la charge s'approche de cette limite, il y a généralement très peu de signes - souvent juste quelques erreurs ou avertissements, ou une charge du processeur supérieure à 80 %.

Lorsque les services web tombent en panne, ils ont tendance à s'interrompre très rapidement. Cela s'explique normalement par le fait qu'une fois que votre système ne peut plus traiter les demandes aussi rapidement qu'elles arrivent, les files d'attente internes de traitement s'accumulent. Votre système doit alors effectuer le travail de traitement, de gestion et de stockage de ses files d'attente internes en plus des demandes, et c'est ce qui fait basculer les serveurs. Très rapidement. Lorsque cela se produit, vos serveurs peuvent, pendant un certain temps, répondre par une page d'erreur, mais cela ne vous aide pas, car les visiteurs qui la voient vont immédiatement cliquer sur Actualiser, ce qui aggrave la charge.

Donc, ne poussez pas vos serveurs plus que nécessaire. Viser les derniers 20 % de capacité de temps processeur ne vaut généralement pas le coup. Si la taille de la file d'attente indiquée dans le portail Queue-Fair (le chiffre et la ligne d'attente en jaune dans les graphiques) diminue ou même augmente plus lentement, minute par minute, et que le temps d'attente indiqué est de 50 minutes ou moins, alors vous traitez les commandes assez rapidement et la file d'attente finira par se vider et cessera d'afficher les pages de file d'attente automatiquement, sans que vous ayez à faire quoi que ce soit, et sans que vous ayez à dire à votre patron que vous l'avez poussée trop fort et l'avez cassée. Vous finirez par y arriver tant que la vitesse du front de la file d'attente est supérieure au nombre d'entrées par minute (tous deux indiqués dans le portail Queue-Fair) - le tournant se situe généralement au moins quelques minutes après le début de chaque événement. Si vous vendez un produit en quantité limitée, vous serez probablement en rupture de stock avant que le point d'inflexion ne soit atteint.

La bonne nouvelle, c'est que si vous réglez accidentellement le taux de file d'attente trop élevé et que vos serveurs craquent, Queue-Fair peut vous aider à reprendre rapidement vos activités - il suffit de mettre la file d'attente en attente jusqu'à ce que vos serveurs soient de nouveau prêts à traiter les visiteurs. En mode attente, les personnes dans la file d'attente voient une page d'attente spéciale que vous pouvez concevoir avant votre événement en ligne. Personne ne peut passer de l'avant de la file d'attente lorsqu'elle est en attente, mais les nouveaux visiteurs Internet peuvent toujours rejoindre la file d'attente à l'arrière, pour être mis en attente de manière équitable une fois le blocage résolu, ce qui se produira très rapidement car Queue-Fair protège votre site de la demande. La page d'attente est une expérience utilisateur supérieure à celle qui consiste à régler le taux d'attente très bas, surtout si vous la mettez à jour pour indiquer aux visiteurs l'heure à laquelle vous prévoyez la réouverture de la file d'attente, ce qui est facile à faire avec l'éditeur de pages du portail, même lorsque des centaines de milliers de personnes sont déjà dans la file d'attente - et en mode d'attente, vous pouvez même les laisser passer un par un avec le bouton unique de Queue-Fair, Admit One, si vous en avez besoin pendant que votre système se remet de sa crise.

Ainsi, si vous constatez que vos serveurs ont besoin de faire une pause pendant votre événement, la page Hold est exactement ce qu'il vous faut pour cela, et elle aidera vos serveurs à se rétablir plus rapidement.

Conclusion

Dans cet article, nous avons expliqué pourquoi une file d'attente basée sur le taux est toujours la meilleure solution, et nous avons donné deux méthodes pour calculer le taux dont vous avez besoin, mais à moins que vous n'ayez effectué un test complet et précis de la charge des visiteurs virtuels sur l'ensemble de votre flux de transactions, et que vous soyez vraiment super extra méga certain de cela, notre conseil est toujours le même :

  1. Commencez avec un taux de file d'attente fixé à 10, ou le taux de transaction d'un jour plus normal.
  2. Surveillez la charge de votre processeur et d'autres indicateurs de performance.
  3. Attendez que les nouvelles commandes soient enregistrées dans votre base de données sql à un rythme identique ou similaire à celui de votre taux d'attente.
  4. Appuyez sur CTRL-SHIFT-R sur vos pages pour vérifier leur réactivité.
  5. Augmentez le taux de file d'attente de 20 % au maximum.
  6. Retournez à l'étape 2, et attendez à nouveau.
  7. Une fois que la taille de la file d'attente diminue ou augmente régulièrement et moins rapidement chaque minute, et que le temps d'attente affiché est inférieur à 50 minutes, il n'est pas nécessaire d'aller plus vite.
  8. Asseyez-vous et détendez-vous ! Queue-Fair s'occupe de vous.

Si vous vendez un produit en quantité limitée, vous ne devez pas non plus prêter attention à l'étape 7.

C'est pour votre première file d'attente, lorsque vous ne connaissez pas le taux d'attente maximum que votre système peut supporter. Pour les files d'attente suivantes, une fois que vous avez mesuré le taux de file d'attente que votre système peut réellement gérer, vous pouvez utiliser le même chiffre - mais seulement si rien n'a changé sur votre système. Dans la pratique, votre système fait probablement l'objet de développements et de modifications constants, et il se peut que vous ne sachiez pas comment les changements récents ont affecté votre taux de file d'attente maximum - alors pourquoi ne pas commencer à la moitié du chiffre mesuré précédemment et répéter le processus ci-dessus ?

N'oubliez pas qu'il vaut toujours mieux prévenir que guérir.


Des centaines d'organisations de premier plan font confiance à nos
solutions de gestion des files d'attente.

Customer 1 Customer 2 Customer 3 Customer 4 Customer 5 Customer 6

La solution simple à l'augmentation de votre trafic internet

Commencez