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.
Traditionnellement, les serveurs de commerce électronique sont dimensionnés pour supporter un nombre maximal d'utilisateurs simultanés, et la charge est souvent définie de cette manière. L'utilisation de cette approche pour gérer une file d'attente pour un site web pose un problème - un problème que nous résolvons avec les tarifs.
Le problème vient du fait que les visiteurs n'utilisent réellement le serveur web que pendant que leur navigateur charge chaque page web.
Par exemple, disons qu'un site de commerce électronique vend des billets. Du début à la fin du parcours du visiteur (la session de l'utilisateur), il y a six pages car le visiteur
L'ensemble du processus de transaction prend cinq minutes, en moyenne.
Supposons, toujours à titre d'exemple, que 100 visiteurs arrivent pour acheter des billets chaque minute, et que le temps moyen pour achever le processus est de cinq minutes. À tout moment, 500 personnes se trouvent en même temps dans le processus de transaction et le serveur doit être dimensionné pour prendre en charge 500 utilisateurs simultanés.
On pourrait penser que l'on pourrait créer un compteur d'utilisateurs simultanés qui serait incrémenté chaque fois qu'un nouveau visiteur arrive sur la page d'accueil, et décrémenté chaque fois qu'un visiteur termine la transaction, et que cela vous indiquerait combien d'utilisateurs un seul serveur gère à tout moment, mais cela ne fonctionnera pas.
Cela ne fonctionnera pas parce que tous les visiteurs n'achèvent pas la transaction. Les gens changent d'avis, sont distraits, ou s'en vont et reviennent plus tard. Comme le serveur Web n'interagit avec les visiteurs que lorsque leur navigateur charge des pages, il n'a aucun moyen de savoir quand cela s'est produit, ni à qui.
Au lieu de cela, pour déterminer qu'un visiteur ne fait plus partie du processus de transaction, le serveur unique doit attendre de voir s'il n'y a plus de demandes de pages provenant de ce visiteur, puis mettre fin à la session de ce dernier. Les délais d'attente doivent toujours être fixés à une durée bien supérieure à la durée moyenne de la transaction (disons 20 minutes dans cet exemple), car certains visiteurs mettent beaucoup plus de temps que d'autres à effectuer leur transaction.
On pourrait ajouter la possibilité de décrémenter le compteur d'utilisateurs simultanés notionnel chaque fois qu'une session de visiteur se termine de cette façon, mais cela donne de très mauvais résultats.
Si 10% des 100 visiteurs qui arrivent chaque minute ne vont pas jusqu'au bout de leur transaction, ceux qui vont jusqu'au bout seront actifs pendant cinq minutes en moyenne et ceux qui ne vont pas jusqu'au bout seront considérés comme actifs pendant au moins 20 minutes toujours (en fait, le délai d'expiration de la session plus la durée moyenne de la session sont plus probables si l'on considère les sessions multiples).
Cela fait 90 * 5 + 10 * 20 = 650, et le serveur signalera 650 utilisateurs simultanés, même s'il est en fait moins occupé !
De plus, 10 * 20 = 200 de ces utilisateurs simultanés n' utilisent pas réellement le site et sont en train de se déconnecter, ce qui représente plus de 30 % des utilisateurs simultanés déclarés, même si seulement 10 % des visiteurs n'achèvent pas la transaction.
Supposons maintenant que l'on souhaite ajouter une file d'attente à ce site, contrôlée par notre compteur d'utilisateurs simultanés. Une fois que le site a atteint sa capacité, une personne qui se trouve en tête de la file d'attente ne pourra accéder au site que lorsque le compteur aura diminué. C'est ce qu'on appelle une file d'attente "one-out-one-in". Dans 30 % des cas, la personne qui se trouve en tête de la file d'attente attendra que quelqu'un qui ne va pas terminer sa transaction finisse par ne pas la terminer.
Il y a aussi le travail d'intégration technique supplémentaire et la charge sur le site web de la création et du fonctionnement du compteur, et du partage de ces informations avec le système de file d'attente. Si le mécanisme de partage ou de comptage tombe en panne ou se brise, la file d'attente est bloquée. Pire encore, si le serveur unique est tellement occupé qu'il ne peut pas mettre à jour le serveur de la file d'attente pour lui dire de laisser entrer la personne suivante, la file d'attente est également bloquée.
Tous ces problèmes sont facilement et simplement résolus en envoyant plutôt les visiteurs du début de la file d'attente à un rythme constant et fixe - dans ce cas, 100 visiteurs par minute.
De cette façon, il n'est pas nécessaire de mesurer le nombre réel d'utilisateurs simultanés, ni de procéder à une intégration complexe avec le site Web de billetterie, ni de risquer que la file d'attente se bloque.
C'est pourquoi nous avons inventé et breveté en 2004 la salle d'attente virtuelle basée sur la tarification pour les sites web très fréquentés.
‘J'adore le service, l'assistance est de premier ordre du début de l'événement jusqu'à la fin. Notre événement s'est déroulé sans problème grâce à Queue-Fair, et tout a fonctionné à merveille 👍 Nous sommes ravis d'avoir choisi le service Queue-Fair. Queue-Fair nous a permis de vendre des billets en ligne pour le spectacle sans que l'infrastructure ne soit touchée et que nous ne soyons en panne. Il n'y a rien à redire - le service est globalement génial.’
‘Une application qui tue le stress ! Nous savions qu'il y aurait une ruée de demandes par le biais d'un nouveau service d'administration en ligne que nous avons lancé. Nous voulions utiliser la file d'attente en permanence pour nous protéger. Queue-Fair nous a fourni une page de file d'attente de marque et des outils faciles à utiliser pour personnaliser et gérer notre salle d'attente. Leur support était excellent et c'était un plaisir de parler avec eux. Queue-Fair a toujours été là pour nous et ce qui est important pour nous, c'est que nous avons obtenu le service dont nous avions besoin. Merci à Queue-Fair !’
‘Une excellente solution pour la gestion d'un trafic important ! L'équipe est très professionnelle et attentive aux besoins des clients. La plateforme est facile à intégrer. Queue-Fair nous aide à gérer les pics inattendus, en s'assurant que notre site web reste fonctionnel pendant les pics de demande.’
‘Génial. J'ai passé une nuit blanche à craindre que le site Web ne tombe à nouveau en panne après la dernière fois que nous avons essayé de lancer notre promotion populaire sans Queue-Fair. Je suis ravi d 'avoir trouvé votre solution. Merci pour votre réactivité - nous apprécions énormément que vous ayez mis en place cette solution pour nous en moins d'une journée et qu'elle ait parfaitement fonctionné. C'est génial. C'est génial. Golden. Merci encore, cela représente beaucoup pour moi. Je vais bien dormir ce soir. Légendaire.’
‘Un produit extrêmement intéressant pour le contrôle du trafic. Nous avions besoin d'une expérience utilisateur fluide les premiers jours du lancement, ce qui n'était possible qu'en ajoutant Queue-Fair. Nous avons apprécié la facilité de configuration de Queue Fair en plusieurs langues. Les possibilités de personnalisation du code étaient importantes et nous avons aligné la salle d'attente sur notre système de conception. L'assistance a été extrêmement utile tout au long du processus. Hautement recommandé. Queue-Fair a fait son travail avec brio.’
‘Ça marche, tout simplement ! Ce fut le lancement le plus facile que nous ayons eu cette année , et de loin. Nous avons vendu tous nos quatre produits principaux et avons fait 20% de plus que prévu. Le système de file d'attente a permis aux gens de sentir qu'ils avaient plus de temps pour faire leurs achats et ils ont donc ajouté d'autres articles à leur panier. L'observation de notre lancement en temps réel nous a donné un aperçu important de nos futurs lancements de produits.’
‘Nous gérons un site de réservation en ligne pour des événements sportifs. Nous avions besoin d'une solution qui nous aiderait à faire face à la charge de nombreuses personnes essayant d'être les premières à réserver. La page de prévente de Queue-Fair a déchargé nos serveurs de cette charge avant l'ouverture des réservations, puis a placé les personnes dans une file d'attente en ligne, renvoyant les visiteurs sur notre site au rythme que nous avons choisi. La solution et le support sont excellents, parfaits pour nos besoins et à un coût abordable. Nous sommes ravis du système et il est doté de nombreuses fonctionnalités utiles, comme la possibilité pour les personnes dans la file d'attente de changer d'appareil sans perdre leur place. Nos visiteurs nous disent même que c'est une bonne idée pour contrôler le trafic sur notre site. Après avoir commencé par un événement spécifique, nous sommes maintenant heureux de protéger l'ensemble de notre site avec Queue-Fair.’
‘Nous avions besoin d'une solution pour le Black Friday! Queue-Fair s'est fait un plaisir de répondre à notre besoin pour cette occasion, en proposant un tarif avantageux et un excellent service client. Nous avons pu mettre en place notre propre salle d'attente personnalisée, notre propre tarif d'entrée, le tout bien adapté à notre mesure. Si vous avez besoin d'une solution sur mesure qui ne vous videra pas les poches, Queue-Fair est la solution qu'il vous faut !’
‘SUCCES !!! La journée d'hier s'est tellement bien déroulée que ma cliente a pleuré. Littéralement. Une expérience fantastique dans son ensemble. Un support incroyable. Un produit incroyable qui a fourni une excellente expérience à l'utilisateur final. Mon client était ravi de voir, depuis le tableau de bord de Queue-Fair, les utilisateurs arriver dans la salle d'attente virtuelle, se rendre sur le site et effectuer leurs achats avec succès.’
‘Très bon rapport qualité-prix et facile à utiliser, très bon produit, facile à mettre en œuvre et à utiliser. Il peut être adapté à différents sites web et pages et son service clientèle est très bon. Il gère la salle d'attente afin de ne pas stresser nos sites web lors du lancement d'événements de billetterie importants. Recommandé !’
‘Facile à utiliser, le meilleur rapport qualité-prix. Queue-Fair est un produit facile à mettre en œuvre qui offre à nos clients qui s'attendent à des pics de ventes une file d'attente en ligne instantanée. Super service - je le recommande à tout le monde.’
‘Un grand merci pour avoir répondu si rapidement à notre demande. Nous avons envoyé un courriel à 21 heures le mercredi et reçu une page de file d'attente entièrement personnalisée et prête à être utilisée le jeudi à 11 heures. Tout simplement génial ! Le tableau de bord et les fonctionnalités sont géniaux - vraiment intuitifs, vraiment propres et faciles à utiliser. Nous avons mis en file d'attente plus de 22 000 personnes pour notre événement de lancement de produit à un coût extrêmement compétitif. Merci beaucoup pour tout ! Je suis vraiment heureux de donner à Queue-Fair un témoignage élogieux et je les recommanderais à toute entreprise qui a besoin d'un système de file d'attente pour son événement ou sa promotion.’
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
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.
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 !
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.
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.
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.
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.
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 ?
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
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 :
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).
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.
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.
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.
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 ralentissement ou de pic de trafic n'est pas à la portée de tous. La meilleure chose à faire est d'effectuer un test de charge en bonne et due forme, 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 IO et les temps de réponse à mesure 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 d'imiter le comportement de chaque utilisateur exactement de la bonne manière (en particulier 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 toute 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 normal, voyez comment cela se passe pendant un certain temps après la mise en vente de vos billets, et si tout semble bon, que la charge de votre processeur est faible, que votre base de données SQL est correcte et (surtout) que vos pages sont réactives lorsque vous appuyez sur CTRL-SHIFT-R, augmentez-le de 20 % au maximum, attendez un peu, et répétez. Vous trouverez bientôt le taux réel dont vous avez besoin au cours de cet "équilibrage de charge" (vous voyez ce que nous avons fait là ?), et n'oubliez pas que, du point de vue de l'expérience client, il n'y a rien de mal à augmenter le taux de file d'attente, car cela entraîne une réduction des temps d'attente estimés par vos clients dans la file d'attente, et tout le monde est heureux de voir un temps de réponse offrant un temps d'attente estimé plus court.
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 !
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é.
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.
Même avant cela, si les visiteurs mettent plus d'une seconde à voir vos pages, ils appuient sur Rafraîchir. Lorsqu'un visiteur clique sur Rafraîchir, votre serveur web ne sait pas qu'il n'attend plus la réponse à la demande initiale. S'il reçoit à la fois la demande initiale et la demande d'actualisation, votre serveur web les traitera toutes les deux. Cela signifie plus de travail pour votre serveur web, des réponses encore plus lentes pour tous vos visiteurs, et plus de gens qui appuient sur rafraîchir, ce qui entraîne un cercle vicieux qui fait échouer votre serveur web avant même qu'il ne commence à envoyer des réponses d'erreur.
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.
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 :
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 ?
Voilà comment utiliser Queue-Fair pour réaliser votre vente en ligne en toute sécurité.
Inventé et breveté en 2004, Queue-Fair est la première salle d'attente virtuelle, qui permet de gérer les files d'attente en ligne pour les sites web et les applications très fréquentés.
2024 The Fair Queue People Ltd. - Tous droits réservés.
Fait partie de la famille de solutions de file d'attente Orderly - OrderlyQ - OrderlyStats - WeQ4U
