W zasadzie nie mogliśmy znaleźć żadnych plusów dla one-out, one-in. W skrócie, problem z tym podejściem polega na tym, że gdy użytkownicy są odwiedzającymi strony e-commerce, serwer internetowy nie wie, ilu współbieżnych użytkowników ma w danym momencie. To jest showstopper. Oto dlaczego.
W dalszej części artykułu opisujemy również, jak korzystać z wirtualnego pokoju opartego na stawkach, aby chronić swoją witrynę.
Tradycyjnie serwery e-commerce są dostarczane do obsługi maksymalnej liczby jednoczesnych użytkowników i obciążenie jest często definiowane w ten sposób. Istnieje problem z wykorzystaniem tego podejścia do uruchomienia kolejki dla strony internetowej - problem ten rozwiązujemy za pomocą stawek.
Problem pojawia się, ponieważ odwiedzający korzystają z serwera WWW tylko w czasie, gdy ich przeglądarka ładuje każdą stronę.
Na przykład, powiedzmy, że witryna e commerce sprzedaje bilety. Od początku podróży odwiedzającego do końca podróży odwiedzającego (sesji użytkownika) jest sześć stron, ponieważ odwiedzający
Cały proces transakcji trwa średnio pięć minut.
Załóżmy, że - znów dla przykładu - co minutę przybywa 100 osób chcących kupić bilety, a średni czas zakończenia procesu wynosi pięć minut. W danym momencie w procesie transakcyjnym uczestniczy jednocześnie 500 osób, a serwer musi być przystosowany do obsługi 500 użytkowników jednocześnie.
Można by pomyśleć, że można by utworzyć licznik użytkowników współbieżnych, który byłby inkrementowany za każdym razem, gdy nowy użytkownik wejdzie na stronę główną, a dekrementowany za każdym razem, gdy użytkownik zakończy transakcję, i w ten sposób można by określić liczbę użytkowników obsługiwanych w danym momencie przez jeden serwer.
To się nie uda, ponieważ nie każdy odwiedzający finalizuje transakcję. Ludzie zmieniają zdanie, rozpraszają się, odchodzą i wracają później. Ponieważ serwer WWW wchodzi w interakcję z odwiedzającymi tylko wtedy, gdy ich przeglądarki ładują strony, nie ma możliwości sprawdzenia, kiedy to się stało ani komu.
Zamiast tego, aby stwierdzić, że odwiedzający nie bierze już udziału w procesie transakcyjnym, pojedynczy serwer musi poczekać, czy nie nadejdzie więcej żądań strony od tego odwiedzającego, a następnie zakończyć sesję tego odwiedzającego. Limity czasu należy zawsze ustawiać na znacznie dłuższy okres niż średni czas transakcji (w tym przykładzie 20 minut), ponieważ niektórzy użytkownicy potrzebują znacznie więcej czasu na dokończenie transakcji niż inni.
Można by dodać funkcję zmniejszania licznika użytkowników współbieżnych za każdym razem, gdy sesja odwiedzającego zakończy się w ten sposób, ale daje to bardzo słabe wyniki.
Jeśli 10% ze 100 odwiedzających, którzy przychodzą co minutę, nie dokończy transakcji, to ci, którzy dokończą, będą aktywni średnio przez pięć minut, a ci, którzy nie dokończą, będą uważani za aktywnych zawsze przez co najmniej 20 minut (w rzeczywistości czas trwania sesji plus średni czas trwania sesji jest bardziej prawdopodobny, jeśli weźmiemy pod uwagę wiele sesji).
To jest 90 * 5 + 10 * 20 = 650, a serwer zgłosi 650 równoczesnych użytkowników, mimo że w rzeczywistości jest mniej obciążony!
Co więcej, aż 10 * 20 = 200 z tych jednoczesnych użytkowników nie korzysta z witryny i jest w trakcie wyczekiwania, co stanowi ponad 30% zgłoszonych jednoczesnych użytkowników, mimo że tylko 10% odwiedzających nie kończy transakcji.
Załóżmy teraz, że chcemy dodać do tej witryny kolejkę, kontrolowaną przez licznik użytkowników współbieżnych. Gdy witryna osiągnie pojemność, osoba stojąca na czele kolejki zostanie wpuszczona na witrynę dopiero po zmniejszeniu się licznika. Jest to tak zwana kolejka typu one-out-one-in. W 30% przypadków osoba stojąca na czele kolejki będzie czekać, aż ktoś, kto nie zamierza zrealizować swojej transakcji, zakończy ją, nie realizując jej.
Do tego dochodzi jeszcze dodatkowa techniczna praca integracyjna i obciążenie strony internetowej związane z tworzeniem i obsługą licznika oraz udostępnianiem tych informacji systemowi kolejkowemu. Jeśli mechanizm udostępniania lub zliczania ulegnie awarii lub zepsuje się, kolejka utknie. Co gorsza, jeśli pojedynczy serwer jest tak zajęty, że nie może zaktualizować danych na serwerze kolejki, aby poinformować serwer kolejki o konieczności wpuszczenia kolejnej osoby, kolejka również utknie.
Wszystkie te problemy można łatwo i prosto rozwiązać, wysyłając odwiedzających z przodu kolejki w stałym, ustalonym tempie - w tym przypadku 100 odwiedzających na minutę.
W ten sposób nie trzeba mierzyć rzeczywistej liczby współbieżnych użytkowników, nie trzeba przeprowadzać skomplikowanej integracji z witryną biletową ani ryzykować, że kolejka utknie.
Właśnie dlatego w 2004 roku wynaleźliśmy i opatentowaliśmy opartą na stawkach Wirtualną Poczekalnię dla ruchliwych stron internetowych.
Niesamowity i łatwy produkt! Queue-Fair jest naprawdę piękny. Tak łatwo ustawić parametry w czasie rzeczywistym i tak łatwo jest również zintegrować. Wsparcie jest reaktywne i przyjazne. Mam skonfigurowaną wirtualną poczekalnię w 15 minut, łącznie z ustawieniami! Więc chronię moją infrastrukturę przed wszystkimi tymi szczytami ruchu z Queue-Fair.
Wasze oprogramowanie sprawiło, że wszyscy byli trzymani w kolejce z dala od naszego serwera i pozwoliło na łagodny przepływ kupujących przez system. To było wspaniałe! Każdy sklep internetowy, który ma pośpiech klientów, znalazłby to naprawdę przydatne. Wielkie dzięki i trzymajcie się dobrej roboty!
Wspaniale! Jesteśmy bardzo zadowoleni i usatysfakcjonowani z Queue-Fair, to wspaniałe mieć taki poziom wsparcia. Usługa działa doskonale - sprzedaliśmy tysiące biletów w krótkim czasie, a Queue-Fair pomogło nam zarządzać ruchem w czasie szczytu! Polecamy Queue-Fair także naszym partnerom serwisowym. Jestem naprawdę szczęśliwy!
Ludzie z Queue-Fair zrobili wszystko, aby pomóc nam wdrożyć ich system kolejkowy w ciągu jednego dnia. Przy ponad 25 000 osób w kolejce, pomogli nam zarządzać ruchem podczas naszych wysokich szczytów. Queue-Fair robi to, do czego jest przeznaczony; ustawia ludzi w kolejce po konkurencyjnej cenie. Jesteśmy zadowoleni z systemu Queue-Fair i będziemy go używać podczas przyszłych wydarzeń.
Queue-Fair to było to, czego potrzebowaliśmy do zarządzania ruchem, a obsługa techniczna jest świetna! System działa bardzo dobrze! Szukaliśmy kilku firm i bez wątpienia znaleźliśmy najlepszą! Dziękujemy bardzo, Queue-Fair!
Wielkie podziękowania za tak szybką realizację naszego zapytania. Wysłaliśmy e-maila w środę o 21:00, a w czwartek o 11:00 otrzymaliśmy gotową do użycia stronę kolejki. Po prostu genialne! Pulpit i funkcje są świetne - naprawdę intuicyjne, czyste i łatwe w użyciu. Ustawiliśmy w kolejce ponad 22 000 osób na nasze wydarzenie związane z wprowadzeniem produktu, a koszt był niezwykle konkurencyjny. Wielkie dzięki za wszystko! Jestem naprawdę szczęśliwy, że mogę wystawić Queue-Fair pochlebne świadectwo i poleciłbym ich każdemu przedsiębiorstwu, które potrzebuje systemu kolejkowego dla swojego wydarzenia lub promocji.
Jeśli wiesz, ilu użytkowników jednocześnie obsługuje serwer WWW oraz jaki jest średni czas transakcji lub czas trwania wizyty od pierwszej strony w strumieniu transakcji do strony potwierdzenia zamówienia, możesz przekształcić to w wskaźnik kolejki, korzystając z prawa Little 'a, dzieląc liczbę użytkowników przez czas trwania, jak poniżej:
Szybkość kolejki = Współbieżni użytkownicy / Czas transakcji
Queue-Fair będzie dostarczać odwiedzających do Twojej witryny w określonym przez Ciebie tempie - dysponujemy zdecydowanie najdokładniejszą w branży sztuczną inteligencją kolejki, która zapewnia, że liczba odwiedzających, jaką chcesz uzyskać w każdej minucie, jest liczbą odwiedzających, jaką otrzymasz w każdej minucie, automatycznie uwzględniając osoby, które nie są obecne, gdy nadchodzi ich kolej, a także osoby, które wracają z opóźnieniem.
Jak to się przekłada na liczbę Współbieżnych Użytkowników? Oczywiście nie każdy odwiedzający Twoją witrynę będzie potrzebował dokładnie takiego samego średniego czasu na sfinalizowanie transakcji, ale dzięki Queue-Fair uzyskasz bardzo stałą liczbę współbieżnych użytkowników, co wynika z prawa wielkich liczb.
Na przykład, załóżmy, że masz wskaźnik kolejki na poziomie 100 odwiedzających na minutę. Wyślemy 100 odwiedzających na Twoją stronę w każdej minucie w stałym strumieniu - to jest to, co robimy i jesteśmy w tym niesamowicie dobrzy. Załóżmy również, że ludzie korzystają z Twojej witryny średnio przez pięć minut, przy czym 70% z nich potrzebuje od 4 do 6 minut od momentu, gdy zostaną przepuszczeni przez kolejkę do momentu, gdy wykonają ostatnie żądanie (niezależnie od tego, czy sfinalizują transakcję, czy nie). Oznacza to odchylenie standardowe wynoszące jedną minutę po obu stronach średniej. Statystycznie rzecz biorąc, oznacza to, że na każdego odwiedzającego, któremu zajmie to pięć i pół minuty, przypada inny, któremu zajmie to cztery i pół minuty, a te różnice w indywidualnym czasie trwania wizyt w ramach wielu sesji mają tendencję do wzajemnego znoszenia się, jeśli w jakikolwiek sposób zliczamy ich wiele. Prawo wielkich liczb mówi, że to wyrównywanie staje się tym dokładniejsze, im większa jest liczba osób biorących udział w badaniu.
Jak dokładnie? Możemy to sprawdzić, korzystając z małej statystyki. Liczebność próby wynosi 5 * 100 = 500, co stanowi dużą liczbę, o której tutaj mowa. Jest to liczba osób, które liczymy. Oznacza to, że błąd standardowy średniej dla czasu transakcji wynosi 1 (odchylenie standardowe, 1 minuta) podzielony przez pierwiastek kwadratowy z wielkości próby (czyli pierwiastek kwadratowy z 500), zgodnie ze wzorem statystycznym na błąd standardowy średniej, co daje błąd standardowy średniej dla czasu transakcji równy 0,044 minuty, czyli zaledwie 2,7 sekundy, czyli mniej niż jeden procent.
Oznacza to, że przy współczynniku kolejki równym 100 i czasie transakcji wynoszącym 5 minut (z dokładnością do minuty) dla każdego odwiedzającego należy oczekiwać od 495 do 505 współbieżnych użytkowników na witrynie przez około 70% czasu, więc matematyka mówi, że użycie kolejki opartej na współczynniku zapewni bardzo stabilne obciążenie serwerów WWW.
Ale czy matematyka jest dokładna? Jest tu kilka subtelności - na przykład wielkość próbki, którą wesoło podnosimy do kwadratu, nie zawsze wynosi dokładnie 500 za każdym razem, gdy zliczani są Współbieżni Użytkownicy (tzn. w danym momencie w czasie), a ponadto rozkład normalny (gaussowski) może dawać ujemne czasy transakcji, które nie występują w rzeczywistości. Dlatego do sprawdzenia tego typu obliczeń używamy symulatora, który mierzy odwiedzającego po odwiedzającym i sekundę po sekundzie. Z powyższych danych wynika, że w 70% przypadków powinieneś spodziewać się od 493 do 507 odwiedzających, a więc matematyka trzyma się bardzo dobrze! Pomiary danych mówią nam również, że witryna będzie miała 500 ± 15 użytkowników współbieżnych przez co najmniej 95% czasu.
Jest to prawdopodobnie bardziej stabilne niż dokładność, z jaką Twój serwer internetowy może zmierzyć liczbę osób korzystających z Twojej witryny! Jeszcze lepsze jest to, że nawet jeśli nie masz pojęcia, jaki jest średni czas transakcji lub odchylenie standardowe dla odwiedzających, te wielkości matematyczne istnieją niezależnie od tego, czy je znasz, czy nie, i tak uzyskasz stabilne obciążenie.
W rezultacie Queue-Fair dostarczy żądaną liczbę odwiedzających na minutę z niemal idealną dokładnością, co skutkuje bardzo stabilną liczbą użytkowników jednocześnie odwiedzających witrynę oraz stabilnym obciążeniem serwera WWW, nad którym masz pełną kontrolę.
Hurra!
A teraz ostrzeżenie. Warto zauważyć, że stabilność liczby jednoczesnych użytkowników na Twojej stronie - a tym samym stabilność obciążenia Twojego serwera - zależy w dużej mierze od tego, jak dokładnie Twój dostawca Wirtualnej Poczekalni wysyła Ci liczbę odwiedzających, których chcesz mieć w każdej minucie, dlatego jest to kluczowy czynnik przy wyborze platformy Wirtualnej Poczekalni. Ponieważ zapewniamy najdokładniejszą Wirtualną Poczekalnię na świecie, nikt nie powstrzyma zalewania Twoich serwerów lepiej niż Queue-Fair.
Co zrobić, jeśli nie wiesz, ilu współbieżnych użytkowników może obsłużyć serwer lub ile wynosi czas transakcji? Możesz przyjrzeć się stronie, która prawdopodobnie stanowi wąskie gardło - zazwyczaj jest to strona, która jest wynikiem kliknięcia przycisku "Kup teraz". Użyj Google Analytics, aby znaleźć miesięczną liczbę unikalnych użytkowników odwiedzających tę stronę, lub policz miesięczne zamówienia. Podziel to przez 30 * 24 * 60 = 43 200, co stanowi liczbę minut w miesiącu (w przybliżeniu). Jest to średnia liczba odwiedzających na minutę w ciągu całego miesiąca. Pomnóż tę liczbę przez trzy. Jest to średnia odwiedzin na minutę w godzinach pracy (w przybliżeniu). Podwój tę wartość. Jest to prawdopodobnie bezpieczna liczba dla wskaźnika Queue Rate.
Na przykład, załóżmy, że realizujesz 100 000 zamówień miesięcznie - oznacza to 100 000 kliknięć przycisku "Kup teraz". To daje 100 000 / 43 200 = 2,31 zamówienia na minutę. Spodziewasz się, że większość tych zamówień będzie miała miejsce w ciągu dnia, a Twoje serwery będą cichsze w nocy, więc pomnóż to przez 3 i otrzymasz 7 zamówień na minutę jako przybliżone oszacowanie tego, jak zajęty jest Twój serwer w godzinach pracy. Jeśli otrzymana liczba jest mniejsza niż 50: będą szczyty i okresy spadku popytu, więc jeśli Twój serwer nie jest zauważalnie powolny w godzinach szczytu, pomnóż tę liczbę przez 2, aby otrzymać 14 aktywnych użytkowników na minutę. Jeśli liczba ta jest większa niż 50: w porównaniu z tym okresy szczytów i spadków będą mniejsze i nie jest bezpieczne podwajanie tej liczby. Liczba, którą uzyskasz, jest prawdopodobnie bezpieczną wartością dla wskaźnika Queue Rate na początek i odpowiada liczbie żądań na sekundę, którą możesz bezpiecznie zarządzać; zawsze możesz ją zwiększyć, jeśli okaże się, że przy tej szybkości systemy nadal odpowiadają na potrzeby użytkowników końcowych.
Jeśli Twoje zamówienia są znakowane czasem, możesz również sprawdzić maksymalną liczbę zamówień, które zostały złożone w ciągu jednej minuty w ciągu ostatniego miesiąca - ale używaj tego z ostrożnością, ponieważ nie wiesz, ile zamówień mogło zostać porzuconych w ciągu tej minuty z powodu spowolnienia serwerów, więc zmniejsz tę wartość o 20%.
W dalszej części artykułu omówiono kilka innych sposobów obliczania szybkości kolejki.
Warto zauważyć, że w powszechnym użyciu istnieją co najmniej dwie definicje pojęcia "współbieżny użytkownik".
Używamy definicji, "liczba osób zaangażowanych w przepływ transakcji w jednym czasie". To kluczowa liczba, którą musisz znać, aby ustawić Queue Rate. To właśnie tylu użytkowników przegląda w tej chwili Twoją witrynę. Liczba Concurrent Sessions jest zwykle nieco większa niż liczba równoczesnych połączeń lub współbieżnych użytkowników, ponieważ niektóre sesje są w trakcie timingu, zwiększając średni czas trwania sesji.
Inaczej jest z liczbą równoczesnych żądań, czyli liczbą żądań HTTP przetwarzanych przez serwer WWW w danym momencie. Bardzo mylące jest to, że wiele osób z branży technicznej mówiąc o liczbie współbieżnych użytkowników, ma na myśli liczbę współbieżnych żądań.
Następnie mamy Concurrent Connections (lub concurrent TCP connections to the same server port on your network interface card), czyli liczbę TCP/IP Sockets otwartych na por cie serwera lub usługi backend w danym momencie. Podczas wykonywania żądań strony, przeglądarki domyślnie pozostawiają połączenie otwarte na wypadek, gdyby strona wykonywała dalsze żądania lub użytkownik przeszedł na inną stronę. To zmniejsza liczbę żądań na sekundę, aby otworzyć nowe połączenia TCP / IP, dzięki czemu proces serwera jest bardziej wydajny. Limity czasu dla tych równoczesnych połączeń różnią się w zależności od przeglądarki, od 60 sekund do nigdy nie zamykania. Twój serwer może również automatycznie zamykać połączenia po okresie braku aktywności. Na serwerach linuksowych możesz uzyskać liczbę równoczesnych połączeń do tego samego portu serwera za pomocą tego polecenia: netstat -aenp | grep ":80 |:443 " | wc -l
Które możesz wypróbować, jeśli jesteś ciekawy. Ponownie, niektórzy ludzie nazywają to również "Współbieżnymi użytkownikami", podczas gdy naprawdę oznacza to współbieżne połączenia.
Jeśli poprosisz swojego dostawcę usług hostingowych o podanie maksymalnej liczby jednoczesnych użytkowników obsługiwanych przez Twój serwer WWW (jak duży jest ruch w szczycie), prawdopodobnie poda on liczbę jednoczesnych sesji, jednoczesnych żądań lub jednoczesnych połączeń, ponieważ nie zna Twojego średniego czasu transakcji, liczby stron w strumieniu transakcji ani żadnych innych informacji, które pozwoliłyby określić liczbę jednoczesnych użytkowników obsługiwanych przez Twój serwer WWW. Wszystkie te liczby mają różne wartości.
Jeśli pytasz swojego dostawcę usług hostingowych lub zespół techniczny o informacje na temat maksymalnych poziomów ruchu, bardzo ważne jest, abyś wyjaśnił, czy chodzi o jednoczesnych użytkowników, jednoczesne sesje, jednoczesne żądania czy jednoczesne połączenia.
Oto dlaczego. Każda strona to pojedyncze żądanie HTTP, ale wszystkie obrazy, skrypty i inne pliki pochodzące z aplikacji internetowej, których przeglądarka używa do wyświetlenia strony, to także żądania HTTP.
Wyobraźmy sobie, że zespół techniczny powiedział Ci, że serwer obsługuje 500 użytkowników jednocześnie, ale tak naprawdę ma na myśli 500 równoczesnych żądań. Biorąc pod uwagę 5-minutowy czas transakcji, korzystasz z powyższego wzoru i zakładasz, że Twoja witryna może obsłużyć 100 odwiedzających na minutę.
Czy to możliwe? Nie.
Gdy ludzie przechodzą przez przepływ transakcji, w rzeczywistości wykonują żądania z Twoich serwerów tylko podczas ładowania każdej strony. Ma to wpływ na ilość ruchu na sekundę lub liczbę aktywnych użytkowników, jaką może obsłużyć Twój serwer. Z pięciu minut czasu trwania transakcji to tylko kilka sekund dla przeciętnego użytkownika. Możesz więc pomyśleć, że 500 równoczesnych żądań oznacza, że możesz obsłużyć znacznie więcej równoczesnych użytkowników, ale możesz się mylić. Czy teraz widzisz, jak skomplikowane jest zrozumienie możliwości witryny pod względem wielkości ruchu lub całkowitej liczby aktywnych użytkowników?
Aby obliczyć maksymalną liczbę Współbieżnych Użytkowników na podstawie maksymalnej łącznej liczby Współbieżnych Żądań, musisz również znać
Prawdopodobnie znasz już punkty 1) i 2) - w naszym przykładzie jest to 6 stron i 5 minut. Możesz łatwo policzyć strony, które widzisz podczas dokonywania transakcji. Jeśli nie znasz średniego czasu transakcji, może Ci go podać Google Analytics lub możesz sprawdzić logi swojego serwera WWW.
W przypadku punktów 3) i 4) pomocna może być przeglądarka Firefox. Kliknij prawym przyciskiem myszy stronę w witrynie, wybierz polecenie Inspect Element (Sprawdź element) i zakładkę Network (Sieć). Następnie naciśnij CTRL-SHIFT-R, aby całkowicie odświeżyć stronę. Na liście zobaczysz czasy ładowania sieci dla każdego elementu strony. Upewnij się, że w kolumnie Transferowane widoczne są rozmiary transferów, ponieważ w przeciwnym razie pliki mogą być obsługiwane z pamięci podręcznej, co może zakłócić obliczenia. Może się okazać, że niektóre skrypty i inne zasoby pochodzą z innych serwerów niż Twoja witryna, dlatego w polu filtra po lewej stronie możesz wpisać nazwę domeny swojej witryny. Aby wyświetlić kolumnę Czas trwania, kliknij prawym przyciskiem myszy nagłówek dowolnej kolumny i wybierz z menu podręcznego pozycję Czas trwania -> Czas trwania. Twój ekran powinien wyglądać tak:
Karta sieci Firefox dla tej strony, pokazująca czas trwania i liczbę żądań od queue-fair.com
Pliki używane do wyświetlania stron mogą pochodzić z wielu różnych witryn, dlatego warto również użyć filtra w lewym górnym rogu, aby pokazywać tylko te z Twojej witryny - ale tylko wtedy, gdy masz pewność , że pliki z innych witryn nie są powodem powolnego ładowania się stron ani częścią wąskiego gardła.
Firefox zlicza żądania w lewej dolnej części ekranu i pokazuje 36 żądań HTTP dla tej jednej strony.
Musisz to zrobić dla każdej strony w swoim przepływie transakcji - policz sumę i podziel przez liczbę stron, aby znaleźć średnią liczbę żądań HTTP dla każdej strony, numer 3) na naszej liście. Teraz widzisz, dlaczego liczba żądań dziecka dla każdej strony HTML jest tak kluczowym czynnikiem dla tego, jak duży ruch może obsłużyć twój serwer internetowy.
W przypadku punktu 4) należy spojrzeć na kolumnę Czas trwania i znaleźć średnią wartość dla wszystkich żądań HTTP dla wszystkich stron. Jeśli nie jesteś pewien, przyjmij pół sekundy - i tak jest w tym sporo niepewności (patrz niżej).
Podajmy kilka przykładowych liczb. Powiedzieliśmy już, że w przykładowym przepływie procesów serwera znajduje się sześć dynamicznych stron, co stanowi 1), oraz że średni czas transakcji wynosi pięć minut, co stanowi 2). Załóżmy 36 żądań HTTP na stronę dla 3), i pół sekundy dla czasu przetwarzania serwera dla każdego żądania HTTP, co jest 4).
Biorąc pod uwagę te liczby, serwer, który może obsłużyć 500 równoczesnych żądań, może obsłużyć 500 / (0,5 sekundy) = 1000 żądań HTTP na sekundę, co oznacza 60 000 żądań HTTP na minutę, gdy jego wydajność jest całkowicie wyczerpana.
W ciągu pięciu minut trwania transakcji może on obsłużyć 5 * 60 000 = 300 000 żądań HTTP. Wydaje się, że to bardzo dużo, prawda?
Jednak na każdego odwiedzającego przypada sześć stron, z których każda wykonuje średnio 36 żądań HTTP, czyli 6 * 36 = 216 żądań
Zatem przepustowość 300 000 żądań HTTP może teoretycznie obsłużyć 300 000 / 216 = 1 389 użytkowników współbieżnych
Hej, to świetnie! Myśleliśmy, że możemy mieć tylko wskaźnik kolejki 100, ale 1 389 / 5 minut = 278 odwiedzających na minutę, więc możemy mieć wyższy wskaźnik kolejki!
Cóż, prawdopodobnie nie. Po pierwsze, odwiedzający nie będą wysyłać zapytań w odstępach dokładnie półsekundowych, jak zakłada powyższe obliczenie. Co ważniejsze, dane wejściowe będą mierzone w czasie, gdy witryna nie jest zajęta. Śmieci na wejściu, śmieci na wyjściu.
Gdy witryna jest zajęta, serwer dłużej przetwarza żądania - można to zauważyć na innych witrynach, gdy strony są zajęte i dłużej się na nie czeka. Zwiększa to średni czas przetwarzania pojedynczego żądania HTTP przez serwer (4), co obniża maksymalną przepustowość. Weźmy więc liczbę 278 użytkowników na minutę i zmniejszmy ją o połowę. Następnie jeszcze raz zmniejsz o połowę. Realnie rzecz biorąc, przy maksymalnym obciążeniu witryny możesz liczyć na około 70 nowych odwiedzających na minutę.
Inne czynniki zakłócające to buforowanie, które oznacza, że przeglądarki odwiedzających nie muszą wykonywać każdego pojedynczego żądania dla każdej pojedynczej strony - to zwykle oznacza, że serwer potrzebuje mniej zasobów i może zwiększyć liczbę nowych odwiedzających na minutę, którą twój serwer może obsłużyć. Balansery obciążenia, które rozkładają obciążenie na kilka serwerów, a także serwowanie statycznych treści zamiast dynamicznych stron może również przyspieszyć proces serwera, ponieważ każdy serwer wymaga mniej zasobów.
Przekonasz się również, że nie wszystkie strony zajmują tyle samo czasu, ponieważ niektóre wymagają mniej zasobów niż inne do produkcji i obsługi. Przeszukiwanie bazy danych, zapytania o wyszukiwanie i aktualizacje trwają najdłużej, więc będziesz miał wąskie gardło gdzieś w swoim procesie, gdzie ludzie piętrzą się, czekając na dane karty kredytowej do przetworzenia i zamówienia przechowywane, lub czekając na dostępność do sprawdzenia. Każdy przepływ transakcji ma najwolniejszy krok, więc zawsze jest gdzieś wąskie gardło, i zawsze istnieje odpowiedź o maksymalnej wartości na pytanie, ilu współbieżnych użytkowników może obsłużyć serwer internetowy - i może być kilka limitów zaangażowanych. W takim przypadku chcesz ustawić swoją szybkość kolejki na tyle nisko, aby zapewnić, że twój serwer ma pojemność czasu cpu, aby przetworzyć wystarczająco dużo ludzi jednocześnie dla najwolniejszego kroku w twoim procesie, aby ludzie nie układali się tam. W przeciwnym razie twój serwer internetowy może dosłownie zmielić się do zatrzymania.
Z naszego doświadczenia wynika, że przy pierwszej sprzedaży wszyscy przeceniają zdolność swoich serwerów do radzenia sobie z dużym natężeniem ruchu.
Wszyscy.
Dokładne określenie średniego czasu trwania sesji i wydajności użytkownika końcowego podczas powolnego lub szczytowego ruchu nie jest dla osób o słabym sercu. Najlepszą rzeczą do zrobienia jest uruchomienie właściwego testu obciążeniowego, z "fałszywymi" klientami faktycznie przechodzącymi przez proces zamówienia podczas testu obciążeniowego dokładnie tak, jak by to miało miejsce w prawdziwym życiu, wykonując te same żądania HTTP w tej samej kolejności, z tymi samymi przerwami między stronami podczas testu obciążeniowego, jak widzisz w prawdziwym życiu, i miej oko na obciążenie procesora, przepustowość IO i czasy odpowiedzi, jak podnieść liczbę wirtualnych gości. Możesz użyć do tego Apache JMeter (lubimy też K6 dla lżejszych obciążeń lub wolniejszych maszyn), ale niezależnie od narzędzia, którego używasz, jest to czasochłonne i trudne do naśladowania zachowanie każdego pojedynczego użytkownika w dokładnie właściwy sposób (zwłaszcza z zawiłościami buforowania). Nawet wtedy weź swoją maksymalną liczbę i zmniejsz ją o połowę.
W przeciwnym razie należy zachować ostrożność.
Możesz łatwo zmienić szybkość kolejki dla dowolnej kolejki Queue-Fair w dowolnym momencie za pomocą portalu Queue-Fair. Zacznij od 10 odwiedzających na minutę lub szybkości transakcji w bardziej normalny dzień, zobacz, jak to działa przez chwilę po tym, jak bilety trafią do sprzedaży, a jeśli wszystko wygląda dobrze, obciążenie procesora jest niskie, baza danych sql jest w porządku i (przede wszystkim) strony reagują po naciśnięciu CTRL-SHIFT-R, podnieś go o nie więcej niż 20 procent, poczekaj chwilę i powtórz. Wkrótce znajdziesz rzeczywistą szybkość, której potrzebujesz podczas tego "równoważenia obciążenia" (widzisz, co tam zrobiliśmy?) I pamiętaj, że z punktu widzenia doświadczenia klienta dobrze jest podnieść szybkość kolejki, ponieważ powoduje to skrócenie szacowanego czasu oczekiwania, który widzą klienci w kolejce, a wszyscy są zadowoleni, widząc czas odpowiedzi zapewniający krótszy szacowany czas oczekiwania.
Należy unikać ustawiania zbyt wysokiego Queue Rate, aby potem nie musieć go obniżać, ponieważ a) oznacza to, że osoby korzystające z witryny doświadczają powolnego ładowania stron oraz b) powoduje to wzrost szacowanego czasu oczekiwania. Wszyscy ludzie w Twojej kolejce będą wzdychać!
Pamiętaj, że gdzieś w procesie zamawiania będzie wąskie gardło - każda transakcja ma swój najwolniejszy etap - i tam będzie się gromadzić wiele sesji. Nie chcesz, aby po minucie sprzedaży biletów okazało się, że obciążenie procesora serwera jest znacznie niższe od maksymalnego, i podnieść stawkę. Odwiedzający prawdopodobnie nie dotarli jeszcze do przycisku "Kup teraz". Należy poczekać, aż baza danych sql będzie zgłaszać nowe zamówienia w takim samym lub podobnym tempie jak wskaźnik kolejki, i dopiero wtedy przeprowadzić pomiary i testy responsywności. Pamiętaj, że za każdym razem, gdy zwiększysz tempo, minie tyle samo czasu, zanim dodatkowi odwiedzający dotrą do wąskiego gardła, więc nie będziesz w stanie dokładnie ocenić, jak działa Twój serwer przy nowym tempie, dopóki nie upłynie ten czas.
Omówiliśmy już, że najlepiej jest stopniowo zwiększać Queue Rate po otwarciu kolejki. Prawdopodobnie zdajesz sobie sprawę, że Twoje serwery mają limit, którego nie można przekroczyć bez awarii systemu, i być może nawet wiesz, jaki jest ten limit - ale możesz nie wiedzieć, że gdy obciążenie zbliża się do tego limitu, zazwyczaj nie ma żadnych oznak - często jest to tylko kilka błędów lub ostrzeżeń albo obciążenie procesora powyżej 80%.
W przypadku awarii usługi sieciowe mają tendencję do bardzo szybkiego "pstrykania" lub zatrzymywania się. Dzieje się tak zazwyczaj dlatego, że gdy system nie jest już w stanie przetwarzać żądań tak szybko, jak one przychodzą, tworzą się wewnętrzne kolejki przetwarzania. System musi wtedy wykonać pracę związaną z przetwarzaniem, zarządzaniem i przechowywaniem swoich wewnętrznych kolejek, a także żądań, i to właśnie powoduje, że serwery przestają działać. Bardzo szybko. Gdy tak się stanie, Twoje serwery mogą przez pewien czas reagować, wyświetlając stronę błędu, ale to Ci nie pomoże, ponieważ odwiedzający, którzy ją zobaczą, natychmiast klikną przycisk Odśwież, co jeszcze bardziej zwiększy obciążenie.
Nawet wcześniej, jeśli odwiedzający potrzebują więcej niż około sekundy, aby zobaczyć Twoje strony, naciskają przycisk Odśwież. Gdy odwiedzający naciśnie przycisk odświeżania, serwer nie wie, że odwiedzający nie czeka już na odpowiedź na pierwotne żądanie. Jeśli odebrane zostanie zarówno oryginalne żądanie, jak i żądanie odświeżenia, serwer przetworzy je oba. Oznacza to więcej pracy dla serwera, jeszcze wolniejsze odpowiedzi dla wszystkich odwiedzających i więcej osób naciskających odświeżanie, co powoduje błędne koło, które zrywa serwer, zanim jeszcze zacznie wysyłać odpowiedzi na błędy.
Więc, nie naciskaj na swoje serwery mocniej niż musisz. Zwykle nie warto ryzykować, aby uzyskać te ostatnie 20% przepustowości cpu. Jeśli rozmiar kolejki pokazany w portalu Queue-Fair (żółta cyfra i linia Waiting na wykresach) maleje lub nawet tylko rośnie wolniej, minuta po minucie, a pokazany czas oczekiwania wynosi 50 minut lub mniej, to znaczy, że przetwarzasz zamówienia wystarczająco szybko i kolejka w końcu opróżni się i przestanie pokazywać strony kolejki automatycznie, bez konieczności robienia czegokolwiek i bez konieczności mówienia szefowi, że zbyt mocno ją popchnąłeś i zepsułeś. Dojdziesz tam w końcu tak długo, jak długo prędkość Czoła Kolejki jest wyższa niż liczba Dołączeń co minutę (oba te wskaźniki są pokazane w Portalu Queue-Fair) - punkt zwrotny jest zwykle co najmniej kilka minut w każdym wydarzeniu. Jeśli sprzedajesz produkt o ograniczonej ilości, prawdopodobnie wyprzedasz się przed osiągnięciem punktu zwrotnego.
Dobrą wiadomością jest to, że jeśli przypadkowo ustawisz zbyt wysoki wskaźnik kolejki i twoje serwery się zatrzasną, Queue-Fair może pomóc ci szybko wrócić do pracy - po prostu umieść kolejkę w trybie wstrzymania, dopóki twoje serwery nie będą gotowe do obsługi odwiedzających ponownie. W trybie Hold, osoby znajdujące się w kolejce widzą specjalną stronę Hold, którą możesz zaprojektować przed wydarzeniem online. Nikt nie jest przepuszczany z przodu kolejki, gdy jest ona wstrzymana, ale nowi internauci mogą nadal dołączać do kolejki z tyłu, aby zostać uczciwie ustawieni w kolejce, gdy blokada zostanie usunięta, co nastąpi bardzo szybko, ponieważ Queue-Fair chroni Twoją witrynę przed popytem. Strona wstrzymania jest lepszym doświadczeniem użytkownika niż ustawienie wskaźnika kolejki na naprawdę niskim poziomie, zwłaszcza jeśli zaktualizujesz ją, aby powiedzieć odwiedzającym, kiedy oczekujesz ponownego otwarcia kolejki, co jest łatwe do zrobienia za pomocą edytora strony portalu, nawet jeśli setki tysięcy ludzi są już w kolejce - a w trybie wstrzymania możesz nawet przepuścić ich pojedynczo za pomocą unikalnego przycisku Queue-Fair Admit One, jeśli musisz, podczas gdy twój system odzyskuje swoje migawki.
Jeśli więc okaże się, że Twoje serwery muszą zrobić sobie przerwę podczas imprezy, strona Wstrzymaj jest właśnie tym, czego potrzebujesz, a dodatkowo pomoże Twoim serwerom szybciej odzyskać sprawność.
W tym artykule wyjaśniliśmy, dlaczego kolejka oparta na stawkach jest zawsze najlepszym rozwiązaniem, i podaliśmy dwie metody obliczania potrzebnej stawki, ale dopóki nie przeprowadzisz pełnych i dokładnych testów obciążenia wirtualnych użytkowników na całym przepływie transakcji i nie jesteś tego naprawdę super ekstra mega pewny, nasza rada jest zawsze taka sama:
Jeśli sprzedajesz produkt w ograniczonej ilości, nie musisz zwracać uwagi na krok 7.
Dotyczy to pierwszej kolejki, gdy nie znasz jeszcze maksymalnego Queue Rate, jakie może obsłużyć twój system. W przypadku kolejnych kolejek, po zmierzeniu współczynnika queue rate, który system może obsłużyć, można użyć tej samej wartości - ale tylko wtedy, gdy w systemie nic się nie zmieniło. W praktyce twój system jest prawdopodobnie stale rozwijany i modyfikowany, a ty możesz nie wiedzieć, jak ostatnie zmiany wpłynęły na maksymalne Queue Rate - dlaczego więc nie zacząć od połowy poprzednio zmierzonej wartości i nie powtórzyć powyższego procesu?
Oto jak używać Queue-Fair, aby Twoja sprzedaż była przyjemna i bezpieczna, i pamiętaj, że zawsze lepiej jest być bezpiecznym niż żałować.
2024 The Fair Queue People Ltd. - Wszystkie prawa zastrzeżone.
Część rodziny rozwiązań kolejkowych Orderly - OrderlyQ - OrderlyStats - WeQ4U
