Πώς η χρήση της online ουράς μας αποτρέπει τη συντριβή του ιστότοπου και τις καταρρεύσεις του - πόσους ταυτόχρονους χρήστες μπορεί να χειριστεί ένας διακομιστής ιστού;

Γιατί να χρησιμοποιήσετε μια Εικονική Αίθουσα Αναμονής με βάση τις τιμές;

Με βάση τον συντελεστή ή ένα-έξω, ένα-έξω; Ζυγίζουμε τα πλεονεκτήματα και τα μειονεκτήματα.

Στην πραγματικότητα δεν μπορέσαμε να βρούμε κανένα πλεονέκτημα για το one-out, one-in. Με λίγα λόγια, το πρόβλημα με αυτή την προσέγγιση είναι ότι όταν οι χρήστες είναι επισκέπτες σε ιστότοπους ηλεκτρονικού εμπορίου, ο διακομιστής ιστού δεν γνωρίζει πόσους ταυτόχρονους χρήστες έχει κάθε στιγμή. Αυτό είναι ένα εμπόδιο. Ακούστε γιατί.

Αργότερα σε αυτό το άρθρο, θα σας πούμε επίσης πώς να χρησιμοποιήσετε ένα εικονικό δωμάτιο με βάση το ρυθμό για να προστατεύσετε και τον ιστότοπό σας.



Η υψηλότερη βαθμολογία Virtual Waiting Room στο G2 και στο SourceForge
Έχουμε την τέλεια βαθμολογία 5.0 / 5 αστέρων!

Οι ευχαριστημένοι πελάτες μας λένε

 

πόσα αιτήματα ένας διακομιστής ιστού μπορεί να διεκπεραιώσει χωρίς επιπλέον πόρους διακομιστή

Πόσους ταυτόχρονους χρήστες μπορεί να διαχειριστεί ένας διακομιστής ιστού;

Εάν γνωρίζετε πόσους ταυτόχρονους χρήστες χειρίζεται ένας διακομιστής ιστού και τον μέσο χρόνο συναλλαγής ή τη διάρκεια επίσκεψης, από την πρώτη σελίδα στη ροή της συναλλαγής σας έως τη σελίδα επιβεβαίωσης της παραγγελίας, μπορείτε να το μετατρέψετε σε ρυθμό ουράς χρησιμοποιώντας τον νόμο του Little, διαιρώντας τον αριθμό των χρηστών με τη διάρκεια, ως εξής:

Ρυθμό ουράς = Ταυτόχρονοι χρήστες / χρόνος συναλλαγής

Πόσο ακριβές είναι ένα σύστημα ουρών αναμονής με βάση τον ρυθμό;

Το Queue-Fair θα παραδώσει επισκέπτες στον ιστότοπό σας με το ρυθμό που εσείς καθορίζετε - διαθέτουμε μακράν την πιο ακριβή τεχνητή νοημοσύνη ουράς στην επιχείρηση για να διασφαλίσουμε ότι ο αριθμός των επισκεπτών που θέλετε κάθε λεπτό είναι ο αριθμός των επισκεπτών που λαμβάνετε κάθε λεπτό, υπολογίζοντας αυτόματα τους ανθρώπους που δεν είναι παρόντες όταν καλείται η σειρά τους, καθώς και τους ανθρώπους που επιστρέφουν αργά.

Πώς αυτό μεταφράζεται σε αριθμό ταυτόχρονων χρηστών; Φυσικά, κάθε επισκέπτης που φτάνει στον ιστότοπό σας δεν θα χρειαστεί τον ακριβή μέσο χρόνο συναλλαγής για να ολοκληρώσει τη συναλλαγή του, αλλά θα έχετε έναν πολύ σταθερό αριθμό ταυτόχρονων χρηστών με το Queue-Fair, λόγω του νόμου των μεγάλων αριθμών.

Για παράδειγμα, ας πούμε ότι έχετε ρυθμό ουράς 100 επισκέπτες ανά λεπτό. Θα στέλνουμε 100 επισκέπτες στον ιστότοπό σας κάθε λεπτό σε μια σταθερή ροή - αυτό κάνουμε και είμαστε εκπληκτικά καλοί σε αυτό. Ας υποθέσουμε επίσης ότι οι άνθρωποι χρησιμοποιούν τον ιστότοπό σας κατά μέσο όρο (μέσος όρος) για πέντε λεπτά, με το 70% αυτών να χρειάζονται μεταξύ 4 και 6 λεπτών από τη στιγμή που περνούν από την ουρά μέχρι τη στιγμή που κάνουν το τελευταίο αίτημα σελίδας (είτε ολοκληρώσουν είτε όχι μια συναλλαγή). Αυτό σημαίνει Τυπική Απόκλιση ενός λεπτού εκατέρωθεν του μέσου όρου. Στατιστικά μιλώντας, αυτό σημαίνει ότι για κάθε επισκέπτη που χρειάζεται πεντέμισι λεπτά, θα υπάρχει ένας άλλος που χρειάζεται τεσσεράμισι λεπτά, και επομένως αυτές οι διακυμάνσεις στη διάρκεια των μεμονωμένων επισκέψεων σε πολλαπλές συνεδρίες τείνουν να αλληλοεξουδετερώνονται όταν μετράτε πολλές από αυτές με οποιονδήποτε τρόπο. Ο νόμος των μεγάλων αριθμών λέει ότι αυτή η ακύρωση γίνεται όλο και πιο ακριβής όσο μεγαλύτερος είναι ο αριθμός των εμπλεκόμενων ατόμων.

λειτουργικό σύστημα μέγιστος αριθμός πόρων διακομιστή ιστού
υπολογισμός του μέσου όρου για ταυτόχρονους χρήστες με διάστημα εμπιστοσύνης

Πόσο ακριβώς, ακριβώς; Μπορούμε να το υπολογίσουμε αυτό με λίγα στατιστικά στοιχεία. Το μέγεθος του δείγματος είναι 5 * 100 = 500, που είναι ο μεγάλος αριθμός που εμπλέκεται εδώ. Τόσα άτομα μετράτε. Αυτό σημαίνει ότι το Τυπικό σφάλμα στον μέσο όρο για τον χρόνο συναλλαγής είναι 1 (η τυπική απόκλιση, 1 λεπτό) διαιρεμένο με την τετραγωνική ρίζα του μεγέθους του δείγματος (άρα την τετραγωνική ρίζα του 500) σύμφωνα με τον στατιστικό τύπο για το Τυπικό σφάλμα στον μέσο όρο, το οποίο δίνει ένα Τυπικό σφάλμα στον μέσο όρο για τον χρόνο συναλλαγής 0,044 λεπτά ή μόλις 2,7 δευτερόλεπτα, δηλαδή λιγότερο από ένα τοις εκατό.

Αυτό σημαίνει ότι με ρυθμό ουράς 100 και χρόνο συναλλαγής 5 λεπτών πάνω-κάτω ένα λεπτό για κάθε μεμονωμένο επισκέπτη, θα πρέπει να περιμένετε μεταξύ 495 και 505 ταυτόχρονους χρήστες στον ιστότοπό σας περίπου στο 70% του χρόνου, οπότε τα μαθηματικά λένε ότι η χρήση μιας ουράς με βάση το ρυθμό θα προσφέρει ένα πολύ σταθερό φορτίο στους διακομιστές ιστού σας, όπως είναι επιθυμητό.

Αλλά είναι τα μαθηματικά ακριβή; Υπάρχουν κάποιες λεπτές λεπτομέρειες εδώ - για παράδειγμα, το μέγεθος του δείγματος που τετραγωνίζουμε χαρούμενα δεν είναι πάντα ακριβώς 500 κάθε φορά που μετριούνται οι ταυτόχρονοι χρήστες (δηλαδή σε κάθε δεδομένη χρονική στιγμή), και επίσης μια κανονική (γκαουσιανή) κατανομή μπορεί να δώσει αρνητικούς χρόνους συναλλαγών που δεν συμβαίνουν στην πραγματική ζωή. Έτσι, χρησιμοποιούμε έναν προσομοιωτή επισκέπτη προς επισκέπτη, δευτερόλεπτο προς δευτερόλεπτο για να κάνουμε μετρήσεις για να ελέγξουμε τέτοιου είδους υπολογισμούς, και αυτό μας λέει ότι με τα παραπάνω στοιχεία, θα πρέπει να περιμένετε μεταξύ 493 και 507 επισκεπτών το 70% του χρόνου, οπότε τα μαθηματικά στέκονται εντυπωσιακά καλά! Η μέτρηση των δεδομένων μας λέει επίσης ότι ο ιστότοπός σας θα έχει 500 ± 15 ταυτόχρονους χρήστες τουλάχιστον στο 95% του χρόνου.

Αυτό είναι μάλλον πιο σταθερό από την ακρίβεια με την οποία ο διακομιστής ιστού σας μπορεί να μετρήσει τον αριθμό των ατόμων που χρησιμοποιούν τον ιστότοπό σας! Ακόμη καλύτερα, το πραγματικά ωραίο πράγμα εδώ είναι ότι ακόμη και αν δεν έχετε ιδέα για το ποιος είναι ο μέσος χρόνος συναλλαγής ή η τυπική απόκλιση για τους επισκέπτες σας, αυτά τα μαθηματικά μεγέθη υπάρχουν είτε τα γνωρίζετε είτε όχι, και θα έχετε έτσι κι αλλιώς σταθερό φορτίο.

Το συμπέρασμα είναι ότι το Queue-Fair θα παρέχει τον αριθμό επισκεπτών ανά λεπτό που θέλετε με σχεδόν απόλυτη ακρίβεια, με αποτέλεσμα έναν πολύ σταθερό αριθμό ταυτόχρονων χρηστών στον ιστότοπό σας και ένα σταθερό φορτίο διακομιστή ιστού στο οποίο έχετε τον απόλυτο έλεγχο.

Ζήτω!


servers capacity can be exceeced with inaccurate queues Και τώρα μια προειδοποίηση. Αξίζει να σημειωθεί ότι η σταθερότητα του αριθμού των ταυτόχρονων χρηστών στον ιστότοπό σας - και επομένως η σταθερότητα του φορτίου του διακομιστή σας - εξαρτάται σε μεγάλο βαθμό από το πόσο ακριβώς ο πάροχος του Virtual Waiting Room σας στέλνει τον αριθμό των επισκεπτών που επιθυμείτε κάθε λεπτό, και επομένως αυτός είναι ένας βασικός παράγοντας όταν επιλέγετε μια πλατφόρμα Virtual Waiting Room. Επειδή παρέχουμε την πιο ακριβή αίθουσα εικονικής αναμονής στον κόσμο, κανείς δεν σταματά την πλημμύρα των διακομιστών σας καλύτερα από την Queue-Fair.

Ένας εύκολος τρόπος υπολογισμού του ρυθμού ουράς

Τι γίνεται αν δεν γνωρίζετε πόσους ταυτόχρονους χρήστες μπορεί να χειριστεί ένας διακομιστής ή το χρόνο συναλλαγών; Μπορείτε να κοιτάξετε τη σελίδα που είναι πιθανό να είναι το σημείο συμφόρησης - συνήθως αυτή που είναι το αποτέλεσμα του πατήματος ενός κουμπιού "Αγοράστε τώρα". Χρησιμοποιήστε το Google Analytics για να βρείτε τους μηνιαίους μοναδικούς επισκέπτες αυτής της σελίδας ή μετρήστε τις μηνιαίες παραγγελίες σας. Διαιρέστε το με 30 * 24 * 60 = 43.200 που είναι ο αριθμός των λεπτών σε ένα μήνα (περίπου). Αυτός είναι ο μέσος όρος των επισκεπτών σας ανά λεπτό για ολόκληρο τον μήνα. Πολλαπλασιάστε το επί τρία. Αυτός είναι ο μέσος όρος των επισκεπτών σας ανά λεπτό κατά τις εργάσιμες ώρες (περίπου). Διπλασιάστε το. Αυτός είναι πιθανώς ένας ασφαλής αριθμός για το Queue Rate που πρέπει να χρησιμοποιήσετε.

Για παράδειγμα, ας υποθέσουμε ότι επεξεργάζεστε 100.000 παραγγελίες το μήνα - δηλαδή 100.000 κλικ στο κουμπί "Αγοράστε τώρα". Αυτό σημαίνει 100.000 / 43.200 = 2,31 παραγγελίες ανά λεπτό. Θα περιμένατε οι περισσότερες από αυτές τις παραγγελίες να γίνονται κατά τη διάρκεια της ημέρας και οι διακομιστές σας να είναι πιο ήσυχοι τη νύχτα, οπότε πολλαπλασιάστε το επί 3 και αυτό είναι 7 παραγγελίες ανά λεπτό ως μια πρόχειρη εκτίμηση του πόσο απασχολημένος είναι ο διακομιστής σας κατά τις εργάσιμες ώρες. Εάν ο αριθμός που προκύπτει είναι μικρότερος από 50: θα υπάρχουν αιχμές και υφέσεις στη ζήτηση, οπότε εάν ο διακομιστής σας δεν είναι αισθητά αργός τις ώρες αιχμής, πολλαπλασιάστε το επί 2 για να λάβετε 14 ενεργούς χρήστες ανά λεπτό. Εάν ο αριθμός είναι μεγαλύτερος από 50: οι κορυφές και οι υφέσεις από λεπτό σε λεπτό θα είναι μικρότερες συγκριτικά και δεν είναι ασφαλές να το διπλασιάσετε. Ο αριθμός στον οποίο καταλήγετε είναι πιθανότατα ένας ασφαλής αριθμός για το Queue Rate για να ξεκινήσετε και αντιστοιχεί στο πόσες αιτήσεις ανά δευτερόλεπτο μπορείτε να διαχειριστείτε με ασφάλεια- μπορείτε πάντα να τον αυξήσετε, αν διαπιστώσετε ότι τα συστήματά σας εξακολουθούν να ανταποκρίνονται για την απόδοση των τελικών χρηστών σε αυτόν τον ρυθμό.

υπολογισμός μέγιστων επιπέδων ενεργών χρηστών για την εφαρμογή ιστού σας

Εάν οι παραγγελίες σας έχουν χρονοσήμανση, μπορείτε επίσης να δείτε τις μέγιστες παραγγελίες που πήρατε σε ένα λεπτό τον τελευταίο μήνα - αλλά χρησιμοποιήστε το με προσοχή, καθώς δεν θα γνωρίζετε πόσες παραγγελίες μπορεί να έχετε απορρίψει κατά τη διάρκεια αυτού του λεπτού λόγω της επιβράδυνσης των διακομιστών σας, οπότε μειώστε το κατά 20%.

Το υπόλοιπο του παρόντος άρθρου αναλύει ορισμένους άλλους τρόπους υπολογισμού του ρυθμού ουράς.

σύγχυση σχετικά με τους ταυτόχρονους χρήστες ταυτόχρονες συνδέσεις ταυτόχρονες συνεδρίες και μέση διάρκεια συνεδριών

Gotcha #1: Ταυτόχρονοι χρήστες vs Ταυτόχρονες αιτήσεις vs Ταυτόχρονες συνδέσεις vs Ταυτόχρονες συνεδρίες

Αξίζει να επισημανθεί ότι υπάρχουν τουλάχιστον δύο ορισμοί του όρου "ταυτόχρονοι χρήστες" στην κοινή χρήση.

Χρησιμοποιούμε τον ορισμό, "ο αριθμός των ατόμων που συμμετέχουν σε μια ροή συναλλαγών ανά πάσα στιγμή". Αυτός είναι ο βασικός αριθμός που πρέπει να γνωρίζετε για να ορίσετε τον ρυθμό ουράς. Αυτός είναι ο αριθμός των χρηστών που βλέπουν τον ιστότοπό σας αυτή τη στιγμή. Ο αριθμός των ταυτόχρονων συνεδριών είναι συνήθως κάπως μεγαλύτερος από τον αριθμό των ταυτόχρονων συνδέσεων ή των ταυτόχρονων χρηστών, επειδή ορισμένες από τις συνεδρίες βρίσκονται στη διαδικασία χρονομέτρησης, αυξάνοντας τη μέση διάρκεια της συνεδρίας.

Σε αντίθεση με το πόσες ταυτόχρονες αιτήσεις, που είναι ο αριθμός των αιτήσεων HTTP που επεξεργάζεται ο διακομιστής ιστού σας κάθε φορά. Κατά πολύ συγκεχυμένο τρόπο, πολλοί τεχνικοί εννοούν πόσες ταυτόχρονες αιτήσεις όταν λένε πόσοι ταυτόχρονοι χρήστες.

Στη συνέχεια, υπάρχει το Concurrent Connections (ή ταυτόχρονες συνδέσεις TCP στην ίδια θύρα διακομιστή στην κάρτα διασύνδεσης δικτύου σας), το οποίο είναι ο αριθμός των TCP/IP Sockets που είναι ανοιχτά στη θύρα του διακομιστή σας ή στην υπηρεσία backend ανά πάσα στιγμή. Κατά την πραγματοποίηση αιτήσεων σελίδας, οι φυλλομετρητές αφήνουν εξ ορισμού τη σύνδεση ανοιχτή σε περίπτωση που πραγματοποιηθούν περαιτέρω αιτήσεις από τη σελίδα ή ο χρήστης μεταβεί σε μια άλλη σελίδα. Αυτό μειώνει τον αριθμό των αιτήσεων ανά δευτερόλεπτο για το άνοιγμα νέων συνδέσεων TCP/IP, καθιστώντας τη διαδικασία του διακομιστή πιο αποδοτική. Τα χρονικά όρια για αυτές τις ταυτόχρονες συνδέσεις ποικίλλουν ανάλογα με το πρόγραμμα περιήγησης, από 60 δευτερόλεπτα έως το να μην κλείνουν ποτέ. Ο διακομιστής σας μπορεί επίσης να κλείνει αυτόματα τις συνδέσεις μετά από μια περίοδο απραξίας. Στους διακομιστές ιστού Linux μπορείτε να λάβετε μια μέτρηση των ταυτόχρονων συνδέσεων στην ίδια θύρα του διακομιστή με αυτή την εντολή:

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

το οποίο μπορείτε να δοκιμάσετε αν είστε περίεργοι. Και πάλι, κάποιοι το αποκαλούν και αυτό "Concurrent Users", ενώ στην πραγματικότητα σημαίνει ταυτόχρονες συνδέσεις.

Πράγματι, αν ζητήσετε από τον πάροχο φιλοξενίας σας να σας πει τον μέγιστο αριθμό ταυτόχρονων χρηστών που διαχειρίζεται ο διακομιστής ιστού σας (πόση κίνηση αιχμής), πιθανότατα θα σας δώσει έναν αριθμό για τις ταυτόχρονες συνεδρίες, τις ταυτόχρονες αιτήσεις ή τις ταυτόχρονες συνδέσεις, για τον απλούστατο λόγο ότι δεν γνωρίζουν τον μέσο χρόνο συναλλαγής σας, τον αριθμό των σελίδων στη ροή των συναλλαγών σας ή οποιαδήποτε άλλη πληροφορία που θα τους επέτρεπε να σας πουν πόσους ταυτόχρονους χρήστες διαχειρίζεται ο διακομιστής ιστού σας. Όλοι αυτοί οι αριθμοί έχουν διαφορετικές τιμές.

Εάν ζητάτε από τον πάροχο φιλοξενίας ή την τεχνική σας ομάδα πληροφορίες σχετικά με τα μέγιστα επίπεδα κίνησης, είναι εξαιρετικά σημαντικό να διευκρινίσετε εάν εννοούν ταυτόχρονοι χρήστες, ταυτόχρονες συνεδρίες, ταυτόχρονες αιτήσεις ή ταυτόχρονες συνδέσεις.

Αν το κάνετε λάθος, μπορεί να καταρρεύσει η ιστοσελίδα σας!

Να γιατί. Κάθε σελίδα είναι ένα ενιαίο αίτημα HTTP, αλλά όλες οι εικόνες, τα σενάρια και τα άλλα αρχεία που προέρχονται από την εφαρμογή ιστού σας και τα οποία χρησιμοποιεί το πρόγραμμα περιήγησης για την εμφάνιση της σελίδας είναι επίσης αιτήματα HTTP.

Ας φανταστούμε ότι η τεχνική σας ομάδα σας είπε ότι ο διακομιστής υποστηρίζει 500 ταυτόχρονους χρήστες, αλλά στην πραγματικότητα εννοεί 500 ταυτόχρονες αιτήσεις. Με το χρόνο συναλλαγής των 5 λεπτών, χρησιμοποιείτε τον παραπάνω τύπο και υποθέτετε ότι ο ιστότοπός σας μπορεί να υποστηρίξει 100 επισκέπτες ανά λεπτό.

Μπορεί; Όχι.

Καθώς οι χρήστες περνούν από τη ροή συναλλαγών, υποβάλλουν αιτήσεις από τους διακομιστές σας μόνο κατά τη διάρκεια της φόρτωσης κάθε σελίδας. Αυτό επηρεάζει την κίνηση ανά δευτερόλεπτο ή τους ενεργούς χρήστες που μπορεί να διαχειριστεί ο διακομιστής σας. Από τον πεντάλεπτο χρόνο συναλλαγής, αυτό είναι μόνο μερικά δευτερόλεπτα για έναν μέσο χρήστη. Επομένως, μπορεί να νομίζετε ότι 500 ταυτόχρονες αιτήσεις σημαίνουν ότι μπορείτε να χειριστείτε πολύ περισσότερους ταυτόχρονους χρήστες, αλλά μπορεί να κάνετε λάθος. Μπορείτε να καταλάβετε τώρα πώς η κατανόηση της χωρητικότητας του ιστότοπού σας από την άποψη του πόσο μεγάλη είναι η επισκεψιμότητα ή ο συνολικός αριθμός των ενεργών χρηστών είναι μια τόσο περίπλοκη υπόθεση;

ασφάλεια πρώτα για τους πόρους του διακομιστή σας όταν υπολογίζετε πόσες αιτήσεις μπορούν να λάβουν οι ιστοσελίδες σας για μια καλή εμπειρία για κάθε χρήστη.

Μετατροπή ταυτόχρονων αιτήσεων σε ταυτόχρονους χρήστες

Για να υπολογίσετε τον μέγιστο αριθμό ταυτόχρονων χρηστών από τον μέγιστο συνολικό αριθμό ταυτόχρονων αιτήσεων, πρέπει επίσης να γνωρίζετε

  1. Ο αριθμός των σελίδων στη ροή της συναλλαγής σας
  2. Ο μέσος χρόνος συναλλαγής του επισκέπτη από την πρώτη σελίδα έως την τελευταία σελίδα στη ροή σας
  3. Πόσες αιτήσεις αποτελούν κάθε σελίδα, κατά μέσο όρο
  4. Ο μέσος χρόνος που χρειάζεται ο διακομιστής σας για να επεξεργαστεί ένα μεμονωμένο αίτημα HTTP

Πιθανότατα γνωρίζετε ήδη τα 1) και 2) - στο παράδειγμά μας είναι 6 σελίδες και 5 λεπτά. Μπορείτε εύκολα να μετρήσετε τις σελίδες που βλέπετε κατά την πραγματοποίηση μιας συναλλαγής. Αν δεν γνωρίζετε τον μέσο χρόνο συναλλαγής, το Google Analytics μπορεί να σας τον πει ή μπορείτε να ελέγξετε τα αρχεία καταγραφής του διακομιστή ιστού σας.

Για τα 3) και 4), το πρόγραμμα περιήγησης Firefox μπορεί να βοηθήσει. Κάντε δεξί κλικ σε μια σελίδα του ιστότοπού σας, επιλέξτε Inspect Element (Επιθεώρηση στοιχείου) και την καρτέλα Network (Δίκτυο). Στη συνέχεια, πατήστε CTRL-SHIFT-R για να ανανεώσετε πλήρως τη σελίδα. Θα δείτε τους χρόνους φόρτωσης δικτύου για κάθε στοιχείο της σελίδας στη λίστα. Θέλετε να βεβαιωθείτε ότι μπορείτε να δείτε τα μεγέθη μεταφοράς στη στήλη Transferred (Μεταφερθέντα), καθώς διαφορετικά τα αρχεία ενδέχεται να εξυπηρετούνται από μια προσωρινή μνήμη, γεγονός που μπορεί να μπερδέψει τους υπολογισμούς σας. Μπορεί να δείτε ότι ορισμένα σενάρια και άλλοι πόροι προέρχονται από διακομιστές διαφορετικούς από τον ιστότοπό σας, οπότε μπορείτε να πληκτρολογήσετε το όνομα τομέα του ιστότοπού σας στο πλαίσιο φίλτρου στα αριστερά. Για να δείτε τη στήλη Διάρκεια, κάντε δεξί κλικ σε οποιαδήποτε επικεφαλίδα στήλης και επιλέξτε Χρονοδιαγράμματα -> Διάρκεια από το αναδυόμενο μενού. Η οθόνη σας θα πρέπει να μοιάζει κάπως έτσι:

η google επεξεργάζεται ένα σωστά ρυθμισμένο nginx με google analytics για το ανέβασμα εικόνων

Η καρτέλα δικτύου του Firefox για αυτή τη σελίδα, που δείχνει τη διάρκεια και τον αριθμό των αιτημάτων από queue-fair.com

Τα αρχεία που χρησιμοποιούνται για την εμφάνιση των σελίδων σας μπορεί να προέρχονται από διάφορους ιστότοπους, οπότε θέλετε επίσης να χρησιμοποιήσετε το φίλτρο πάνω αριστερά για να εμφανίσετε μόνο τα αρχεία από τον ιστότοπό σας - αλλά μόνο αν είστε βέβαιοι ότι αυτά τα αρχεία από άλλους ιστότοπους δεν είναι η αιτία για την αργή φόρτωση της σελίδας ή μέρος του σημείου συμφόρησης.

Ο Firefox μετράει τις αιτήσεις για εσάς στο κάτω αριστερό μέρος της οθόνης και εμφανίζει 36 αιτήσεις HTTP μόνογια αυτή τη σελίδα.

Πρέπει να το κάνετε αυτό για κάθε σελίδα στη ροή συναλλαγών σας - μετρήστε το σύνολο και διαιρέστε το με τον αριθμό των σελίδων για να βρείτε το μέσο αριθμό αιτήσεων HTTP για κάθε σελίδα, αριθμός 3) στη λίστα μας. Μπορείτε τώρα να καταλάβετε γιατί ο αριθμός των παιδικών αιτήσεων για κάθε σελίδα HTML είναι ένας τόσο βασικός παράγοντας για το πόση κίνηση μπορεί να διαχειριστεί ο διακομιστής ιστού σας.

Για το νούμερο 4), πρέπει να κοιτάξετε τη στήλη Διάρκεια και να βρείτε το μέσο όρο για όλες τις αιτήσεις HTTP για όλες τις σελίδες σας. Αν δεν είστε σίγουροι, υποθέστε μισό δευτερόλεπτο - υπάρχει μεγάλη αβεβαιότητα σε αυτό ούτως ή άλλως (βλ. παρακάτω).

να κάνετε τα μαθηματικά για να υπολογίσετε πόσες συνεδρίες ταυτόχρονα, πόσοι χρήστες και πόσες αιτήσεις ανά δευτερόλεπτο στην εφαρμογή ιστού σας, είτε πρόκειται για ενιαίο διακομιστή είτε για στατικό περιεχόμενο.

Κάνοντας τα μαθηματικά

Ας δώσουμε μερικά παραδείγματα αριθμών. Έχουμε ήδη πει ότι υπάρχουν έξι δυναμικές σελίδες στη ροή διεργασιών του παραδείγματος διακομιστή, που είναι το 1), και ότι ο μέσος χρόνος συναλλαγής είναι πέντε λεπτά, που είναι το 2). Ας υποθέσουμε 36 αιτήσεις HTTP ανά σελίδα για το 3) και μισό δευτερόλεπτο για το χρόνο επεξεργασίας του διακομιστή για κάθε αίτηση HTTP, που είναι το 4).

Με αυτούς τους αριθμούς, ένας διακομιστής που μπορεί να διαχειριστεί 500 ταυτόχρονες αιτήσεις μπορεί να διαχειριστεί 500 / (0,5 δευτερόλεπτα) = 1000 αιτήσεις HTTP ανά δευτερόλεπτο, δηλαδή 60.000 αιτήσεις HTTP ανά λεπτό, όταν είναι πλήρως εξαντλημένος.

Κατά τη διάρκεια της πεντάλεπτης συναλλαγής, μπορεί να χειριστεί 5 * 60.000 = 300.000 αιτήσεις HTTP. Φαίνεται πολύ, σωστά;

Αλλά, για κάθε επισκέπτη, υπάρχουν έξι σελίδες με κατά μέσο όρο 36 αιτήσεις HTTP η καθεμία, οπότε 6 * 36 = 216 αιτήσεις.

Έτσι, η χωρητικότητα των 300.000 αιτήσεων HTTP μπορεί θεωρητικά να διαχειριστεί 300.000 / 216 = 1.389 ταυτόχρονους χρήστες.

Gotcha #2: Οι διακομιστές Web γίνονται πιο αργοί με το φορτίο

Έι, αυτό είναι υπέροχο! Νομίζαμε ότι θα μπορούσαμε να έχουμε ρυθμό αναμονής μόνο 100, αλλά 1.389 / 5 λεπτά = 278 επισκέπτες ανά λεπτό, οπότε μπορούμε να έχουμε υψηλότερο ρυθμό αναμονής!

Λοιπόν, μάλλον όχι. Πρώτον, οι επισκέπτες σας δεν θα στέλνουν αιτήματα σε χρονικά διαστήματα ακριβώς μισού δευτερολέπτου, όπως υποθέτει ο παραπάνω υπολογισμός. Το πιο σημαντικό είναι ότι θα έχετε μετρήσει τα δεδομένα εισόδου σας όταν ο ιστότοπος δεν είναι απασχολημένος. Σκουπίδια μέσα, σκουπίδια έξω.

Όταν ο ιστότοπος είναι απασχολημένος, ο διακομιστής χρειάζεται περισσότερο χρόνο για να επεξεργαστεί τα αιτήματα - θα το έχετε παρατηρήσει αυτό σε άλλους ιστότοπους, όταν τα πράγματα είναι απασχολημένα, ότι περιμένετε περισσότερο για τις σελίδες. Αυτό αυξάνει το μέσο χρόνο που χρειάζεται ο διακομιστής σας για να επεξεργαστεί ένα μεμονωμένο αίτημα HTTP (4), γεγονός που μειώνει τη μέγιστη απόδοση. Πάρτε λοιπόν τους 278 επισκέπτες ανά λεπτό και μειώστε τους στο μισό. Στη συνέχεια, μειώστε το ξανά στο μισό. Πιθανώς ρεαλιστικά να έχετε περίπου 70 νέους επισκέπτες ανά λεπτό στο μέγιστο φορτίο.

όσο βαρύτερο είναι το φορτίο από τις αυξήσεις της κίνησής σας, τόσο πιο αργές γίνονται οι μηχανές.

Άλλοι παράγοντες που προκαλούν σύγχυση περιλαμβάνουν την προσωρινή αποθήκευση δεδομένων, η οποία σημαίνει ότι τα προγράμματα περιήγησης των επισκεπτών σας μπορεί να μην χρειάζεται να κάνουν κάθε αίτηση για κάθε σελίδα - αυτό σημαίνει ότι ο διακομιστής χρειάζεται λιγότερους πόρους και μπορεί να αυξήσει τον αριθμό των νέων επισκεπτών ανά λεπτό που μπορεί να διαχειριστεί ο διακομιστής σας. Οι εξισορροπητές φορτίου που κατανέμουν το φορτίο σε διάφορους διακομιστές και η εξυπηρέτηση στατικού περιεχομένου αντί για δυναμικές σελίδες μπορούν επίσης να επιταχύνουν τη διαδικασία του διακομιστή σας, καθώς κάθε διακομιστής απαιτεί λιγότερους πόρους.

Θα διαπιστώσετε επίσης ότι δεν χρειάζονται όλες οι σελίδες τον ίδιο χρόνο για να ολοκληρωθούν, καθώς ορισμένες απαιτούν λιγότερους πόρους από άλλες για να παραχθούν και να σερβιριστούν. Οι αναζητήσεις σε βάσεις δεδομένων, τα ερωτήματα αναζήτησης και οι ενημερώσεις διαρκούν περισσότερο, οπότε θα έχετε ένα σημείο συμφόρησης κάπου στη διαδικασία σας, όπου οι άνθρωποι συσσωρεύονται, περιμένοντας να επεξεργαστούν τα στοιχεία της πιστωτικής κάρτας και να αποθηκευτούν οι παραγγελίες ή περιμένοντας να ελεγχθεί η διαθεσιμότητα. Κάθε ροή συναλλαγής έχει ένα πιο αργό βήμα, οπότε πάντα υπάρχει κάπου ένα σημείο συμφόρησης, και πάντα υπάρχει μια απάντηση μέγιστης τιμής στην ερώτηση πόσους ταυτόχρονους χρήστες μπορεί να διαχειριστεί ένας διακομιστής ιστού - και μπορεί να υπάρχουν διάφορα όρια. Σε αυτή την περίπτωση, θέλετε να ρυθμίσετε το Queue Rate αρκετά χαμηλά ώστε να διασφαλίσετε ότι ο διακομιστής σας έχει χωρητικότητα χρόνου cpu για να επεξεργαστεί αρκετούς ανθρώπους ταυτόχρονα για το πιο αργό βήμα της διαδικασίας σας, ώστε να μην συσσωρεύονται οι άνθρωποι εκεί. Διαφορετικά, ο webserver σας μπορεί κυριολεκτικά να σταματήσει.

αβέβαιος τρόπος εκτίμησης των πόρων των διακομιστών χωρητικότητας του διακομιστή για κάθε χρήστη

Τι κάνω λοιπόν;

Η εμπειρία μας είναι ότι, ξεκινώντας την πρώτη τους πώληση, όλοι υπερεκτιμούν την ικανότητα των διακομιστών τους να αντεπεξέλθουν σε μεγάλο όγκο κίνησης.

Όλοι.

Ο ακριβής προσδιορισμός της μέσης διάρκειας συνεδρίας και της απόδοσης του τελικού χρήστη κατά τη διάρκεια αργής ή μέγιστης κίνησης δεν είναι για τους αδύναμους. Το καλύτερο που έχετε να κάνετε είναι να εκτελέσετε μια σωστή δοκιμή φόρτου, με "ψεύτικους" πελάτες που πραγματικά περνούν από τη διαδικασία παραγγελίας κατά τη διάρκεια της δοκιμής φόρτου ακριβώς όπως θα έκαναν στην πραγματική ζωή, κάνοντας τα ίδια αιτήματα HTTP με την ίδια σειρά, με τις ίδιες αναμονές μεταξύ των σελίδων κατά τη δοκιμή φόρτου όπως βλέπετε στην πραγματική ζωή, και να παρακολουθείτε το φορτίο του επεξεργαστή σας, την απόδοση IO και τους χρόνους απόκρισης καθώς αυξάνετε τον αριθμό των εικονικών επισκεπτών. Μπορείτε να χρησιμοποιήσετε το Apache JMeter γι' αυτό (μας αρέσει επίσης το K6 για ελαφρύτερα φορτία ή πιο αργά μηχανήματα), αλλά όποιο εργαλείο κι αν χρησιμοποιήσετε, είναι χρονοβόρο και δύσκολο να μιμηθείτε τη συμπεριφορά κάθε χρήστη με τον σωστό ακριβώς τρόπο (ειδικά με την πολυπλοκότητα της προσωρινής αποθήκευσης). Ακόμα και τότε, πάρτε τον μέγιστο αριθμό σας και μειώστε τον στο μισό.

Ελλείψει αυτού, προτιμήστε την προσοχή.

Μπορείτε εύκολα να αλλάξετε τον ρυθμό ουράς για οποιαδήποτε ουρά Queue-Fair ανά πάσα στιγμή χρησιμοποιώντας την πύλη Queue-Fair. Ξεκινήστε με 10 επισκέπτες ανά λεπτό, ή με το ρυθμό συναλλαγών σας σε μια πιο κανονική ημέρα, δείτε πώς πάει για λίγο μετά την έναρξη της πώλησης των εισιτηρίων σας, και αν όλα φαίνονται καλά, το φορτίο του επεξεργαστή σας είναι χαμηλό, η βάση δεδομένων sql είναι μια χαρά και (πάνω απ' όλα) οι σελίδες σας ανταποκρίνονται όταν πατάτε το πλήκτρο CTRL-SHIFT-R, αυξήστε το κατά όχι περισσότερο από 20%, περιμένετε λίγο και επαναλάβετε. Σύντομα θα βρείτε τον πραγματικό ρυθμό που χρειάζεστε κατά τη διάρκεια αυτής της "εξισορρόπησης φορτίου" (βλέπετε τι κάναμε εκεί;), και να θυμάστε, από την άποψη της εμπειρίας των πελατών, είναι καλό να αυξήσετε τον ρυθμό ουράς, καθώς αυτό προκαλεί μείωση των εκτιμώμενων αναμονών που βλέπουν οι πελάτες σας στην ουρά και όλοι είναι ευχαριστημένοι που βλέπουν έναν χρόνο απόκρισης που προσφέρει μια μικρότερη εκτιμώμενη αναμονή.

Αυτό που θέλετε να αποφύγετε είναι να ρυθμίσετε το Queue Rate πολύ ψηλά και στη συνέχεια να χρειαστεί να το μειώσετε, καθώς αυτό α) σημαίνει ότι τα άτομα που χρησιμοποιούν τον ιστότοπο αντιμετωπίζουν αργές φορτώσεις σελίδων και β) προκαλεί αύξηση των εκτιμώμενων αναμονών. Όλοι οι άνθρωποι στην ουρά σας θα αναστενάζουν!

Gotcha #3: Αύξηση του ρυθμού πολύ γρήγορα μετά το άνοιγμα μιας ουράς

Θυμηθείτε, θα έχετε ένα σημείο συμφόρησης κάπου στη διαδικασία παραγγελίας σας - κάθε συναλλαγή έχει ένα πιο αργό βήμα - και θα έχετε πολλαπλές συνεδρίες που συσσωρεύονται εκεί. Αυτό που δεν θέλετε να κάνετε είναι να φτάσετε ένα λεπτό στην πώληση των εισιτηρίων σας, να δείτε ότι ο φόρτος του επεξεργαστή του διακομιστή σας είναι πολύ κάτω από τον μέγιστο αριθμό του και να αυξήσετε τον ρυθμό. Οι επισκέπτες σας πιθανότατα δεν έχουν φτάσει μέχρι το κουμπί "Αγοράστε τώρα". Θέλετε να περιμένετε μέχρι η βάση δεδομένων sql σας να αναφέρει νέες παραγγελίες με τον ίδιο ή παρόμοιο ρυθμό με τον ρυθμό ουράς σας και να κάνετε τότε τις μετρήσεις και τις δοκιμές απόκρισης. Να θυμάστε ότι κάθε φορά που αυξάνετε τον ρυθμό, θα χρειαστεί ο ίδιος χρόνος για να φτάσουν οι επιπλέον επισκέπτες στο σημείο συμφόρησης, οπότε δεν θα είστε σε θέση να αξιολογήσετε με ακρίβεια πώς αποδίδει ο διακομιστής σας με τον νέο ρυθμό μέχρι να παρέλθει αυτός ο χρόνος.

επιβραδύνει την απόφαση για κατανάλωση πόρων του διακομιστή
διακομιστές snap όταν υπερβαίνεται η χωρητικότητα των διακομιστών

Gotcha #4: Χτυπώντας τους διακομιστές σας

Έχουμε ήδη συζητήσει πώς είναι καλύτερο να αυξάνετε σταδιακά τον ρυθμό ουράς μόλις ανοίξει η ουρά σας. Πιθανόν να γνωρίζετε ότι οι διακομιστές σας έχουν ένα όριο που δεν μπορεί να ξεπεραστεί χωρίς να καταρρεύσει το σύστημα και ίσως να γνωρίζετε ακόμη και ποιο είναι το όριο - αλλά αυτό που ίσως δεν γνωρίζετε είναι ότι καθώς το φορτίο πλησιάζει αυτό το όριο, συνήθως υπάρχει πολύ μικρή ένδειξη - συχνά μόνο μερικά σφάλματα ή προειδοποιήσεις ή ένα φορτίο επεξεργαστή πάνω από 80%.

Όταν οι υπηρεσίες ιστού αποτυγχάνουν, τείνουν να "σπάσουν" ή να καταστραφούν πολύ γρήγορα. Αυτό συμβαίνει συνήθως επειδή, όταν το σύστημά σας δεν μπορεί πλέον να επεξεργαστεί τα αιτήματα τόσο γρήγορα όσο έρχονται, δημιουργούνται εσωτερικές ουρές επεξεργασίας. Το σύστημά σας πρέπει στη συνέχεια να κάνει τη δουλειά της επεξεργασίας, διαχείρισης και αποθήκευσης των εσωτερικών ουρών του καθώς και των αιτήσεων, και αυτό είναι που ανατρέπει τους διακομιστές στα άκρα. Πολύ γρήγορα. Μόλις συμβεί αυτό, οι διακομιστές σας μπορεί για κάποιο χρονικό διάστημα να είναι σε θέση να ανταποκριθούν με μια σελίδα σφάλματος, αλλά αυτό δεν σας βοηθάει, επειδή οι επισκέπτες που θα τη δουν θα πατήσουν αμέσως το κουμπί Ανανέωση, επιδεινώνοντας το φορτίο.

Ακόμα και πριν από αυτό, αν οι επισκέπτες χρειάζονται περισσότερο από ένα δευτερόλεπτο για να δουν τις σελίδες σας, πατάνε Refresh. Όταν ένας επισκέπτης πατάει ανανέωση, ο διακομιστής ιστού σας δεν γνωρίζει ότι ο επισκέπτης δεν περιμένει πλέον την απάντηση στο αρχικό αίτημα. Εάν ληφθεί τόσο το αρχικό όσο και το αίτημα ανανέωσης, ο διακομιστής ιστού θα τα επεξεργαστεί και τα δύο. Αυτό σημαίνει περισσότερη δουλειά για τον διακομιστή ιστού σας, ακόμη πιο αργές απαντήσεις για όλους τους επισκέπτες σας και περισσότερους ανθρώπους που πατούν ανανέωση, με αποτέλεσμα έναν φαύλο κύκλο που σπάει τον διακομιστή ιστού σας πριν καν αρχίσει να στέλνει απαντήσεις σφάλματος.

Επομένως, μην πιέζετε τους διακομιστές σας περισσότερο από όσο χρειάζεται. Το να προσπαθείτε για το τελευταίο 20% της χωρητικότητας του επεξεργαστή δεν αξίζει συνήθως το ρίσκο. Εάν το μέγεθος της ουράς που εμφανίζεται στην Πύλη Queue-Fair (το κίτρινο σχήμα και η γραμμή αναμονής στα διαγράμματα) μειώνεται ή ακόμη και απλά αυξάνεται πιο αργά, λεπτό προς λεπτό, και ο χρόνος αναμονής που εμφανίζεται είναι 50 λεπτά ή λιγότερο, τότε επεξεργάζεστε τις παραγγελίες αρκετά γρήγορα και η ουρά θα αδειάσει τελικά και θα σταματήσει να εμφανίζει αυτόματα τις Σελίδες αναμονής, χωρίς να χρειαστεί να κάνετε τίποτα, και χωρίς να χρειαστεί να πείτε στο αφεντικό σας ότι τον πιέσατε πολύ και τον χαλάσατε. Θα φτάσετε εκεί τελικά, εφόσον η ταχύτητα του Μπροστινού μέρους της Ουράς είναι υψηλότερη από τον αριθμό των Ενώσεων κάθε λεπτό (και τα δύο εμφανίζονται στην Πύλη Queue-Fair) - το σημείο καμπής είναι συνήθως τουλάχιστον μερικά λεπτά μετά από κάθε γεγονός. Εάν πουλάτε ένα προϊόν περιορισμένης ποσότητας, πιθανότατα θα εξαντληθείτε πριν φτάσετε στο σημείο καμπής.

Τα καλά νέα είναι ότι αν κατά λάθος ρυθμίσετε το Queue Rate πολύ ψηλά και οι διακομιστές σας σπάσουν, το Queue-Fair μπορεί να σας βοηθήσει να επαναφέρετε τη λειτουργία σας γρήγορα - απλά θέστε την ουρά σε αναμονή μέχρι οι διακομιστές σας να είναι έτοιμοι να διαχειριστούν ξανά επισκέπτες. Στη λειτουργία αναμονής, οι άνθρωποι στην ουρά βλέπουν μια ειδική σελίδα αναμονής που μπορείτε να σχεδιάσετε πριν από την online εκδήλωσή σας. Κανείς δεν αφήνεται να περάσει από το μπροστινό μέρος της ουράς όταν αυτή είναι σε κατάσταση αναμονής, αλλά οι νέοι επισκέπτες του διαδικτύου μπορούν να ενταχθούν στην ουρά στο πίσω μέρος, για να μπουν σε μια δίκαιη ουρά μόλις λυθεί το μπλοκάρισμα, πράγμα που θα συμβεί πολύ γρήγορα, επειδή το Queue-Fair προστατεύει τον ιστότοπό σας από τη ζήτηση. Η Σελίδα Αναμονής είναι μια ανώτερη εμπειρία για τον χρήστη από το να ρυθμίσετε το Ρυθμό Αναμονής πολύ χαμηλά, ειδικά αν την ενημερώσετε για να πείτε στους επισκέπτες τι ώρα περιμένετε να ανοίξει ξανά η Ουρά, κάτι που είναι εύκολο να γίνει με τον επεξεργαστή σελίδας της Πύλης, ακόμα και όταν εκατοντάδες χιλιάδες άνθρωποι είναι ήδη στην ουρά - και στη λειτουργία Αναμονής μπορείτε ακόμα και να τους αφήσετε να περάσουν ένας-ένας με το μοναδικό κουμπί Admit One του Queue-Fair, αν χρειαστεί, ενώ το σύστημά σας θα ανακάμπτει από το σπάσιμο.

Έτσι, αν διαπιστώσετε ότι οι διακομιστές σας πρέπει να κάνουν ένα διάλειμμα κατά τη διάρκεια της εκδήλωσής σας, η σελίδα Hold είναι ακριβώς αυτό που χρειάζεστε για αυτό, και θα βοηθήσει τους διακομιστές σας να ανακάμψουν πιο γρήγορα.

Συμπέρασμα

Σε αυτό το άρθρο εξηγήσαμε γιατί μια ουρά με βάση το ρυθμό είναι πάντα ο καλύτερος τρόπος και δώσαμε δύο μεθόδους για τον υπολογισμό του ρυθμού που χρειάζεστε, αλλά αν δεν έχετε κάνει πλήρη και ακριβή εικονική δοκιμή φορτίου επισκεπτών σε ολόκληρη τη ροή συναλλαγών σας και δεν είστε πραγματικά πολύ σίγουροι γι' αυτό, η συμβουλή μας είναι πάντα η ίδια:

  1. Ξεκινήστε με ένα Queue Rate που έχει οριστεί στο 10 ή το ρυθμό συναλλαγών σας σε μια πιο κανονική ημέρα.
  2. Παρακολουθήστε το φορτίο του επεξεργαστή σας και άλλους δείκτες επιδόσεων.
  3. Περιμένετε έως ότου οι νέες παραγγελίες καταγραφούν στη βάση δεδομένων sql με τον ίδιο ή παρόμοιο ρυθμό με τον ρυθμό ουράς σας.
  4. Πατήστε CTRL-SHIFT-R στις σελίδες σας για να ελέγξετε την απόκριση.
  5. Αυξήστε τον ρυθμό ουράς κατά 20% το πολύ.
  6. Επιστρέψτε στο Βήμα 2 και περιμένετε ξανά.
  7. Όταν το μέγεθος της ουράς μειώνεται ή αυξάνεται σταθερά με μικρότερο ρυθμό κάθε λεπτό και ο χρόνος αναμονής που εμφανίζεται είναι μικρότερος από 50 λεπτά, δεν χρειάζεται να πάει πιο γρήγορα.
  8. Καθίστε αναπαυτικά και χαλαρώστε! Το Queue-Fair σας έχει καλύψει.

Εάν πουλάτε ένα προϊόν περιορισμένης ποσότητας, δεν χρειάζεται να δώσετε προσοχή ούτε στο βήμα 7.

Αυτό ισχύει για την πρώτη σας ουρά, όταν δεν γνωρίζετε τον πραγματικό μέγιστο ρυθμό ουράς που μπορεί να υποστηρίξει το σύστημά σας. Για τις επόμενες ουρές, αφού μετρήσετε το Queue Rate που μπορεί να διαχειριστεί το σύστημά σας, ίσως μπορέσετε να χρησιμοποιήσετε ξανά τον ίδιο αριθμό - αλλά μόνο αν δεν έχει αλλάξει τίποτα στο σύστημά σας. Στην πράξη, το σύστημά σας πιθανόν να βρίσκεται υπό συνεχή ανάπτυξη και τροποποίηση και μπορεί να μην γνωρίζετε πώς οι πρόσφατες αλλαγές έχουν επηρεάσει το μέγιστο ρυθμό ουράς - οπότε γιατί να μην ξεκινήσετε από το μισό του προηγούμενου μετρημένου αριθμού και να επαναλάβετε την παραπάνω διαδικασία;

Αυτός είναι λοιπόν ο τρόπος με τον οποίο μπορείτε να χρησιμοποιήσετε το Queue-Fair για να κάνετε την onsale σας ωραία και ασφαλή, και να θυμάστε, είναι πάντα καλύτερα να είστε σίγουροι παρά να λυπάστε.


Εκατοντάδες κορυφαίοι οργανισμοί εμπιστεύονται τις λύσεις μας για ουρές αναμονής

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

Η απλή λύση για την αύξηση της κίνησης στο διαδίκτυο

Ξεκινήστε