Nie udało nam się znaleźć żadnych zalet podejścia "one-out, one-in". W skrócie, problem z tym podejściem polega na tym, że gdy użytkownicy są odwiedzającymi strony internetowe, serwer WWW nie wie, ilu użytkowników współbieżnych ma w danym momencie. Jest to przeszkoda. 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 są przystosowane do obsługi maksymalnej liczby współbieżnych użytkowników i w ten sposób często definiuje się ich obciążenie. Istnieje problem z wykorzystaniem tego podejścia do obsługi kolejki dla witryny internetowej - problem ten rozwiązujemy za pomocą wskaźników.
Problem pojawia się, ponieważ odwiedzający korzystają z serwera WWW tylko w czasie, gdy ich przeglądarka ładuje każdą stronę.
Na przykład załóżmy, że witryna sprzedaje bilety. Od początku podróży odwiedzającego do jej końca (sesji użytkownika) znajduje się sześć stron, na których 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.
Dlatego właśnie w 2004 roku wymyśliliśmy i opatentowaliśmy opartą na stawkach Wirtualną poczekalnię dla stron internetowych o dużym natężeniu ruchu.
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".
Posługujemy się definicją: "liczba osób zaangażowanych w przepływ transakcji w danym momencie". Jest to kluczowa liczba, którą należy znać, aby ustawić wskaźnik kolejki. Jest to liczba użytkowników, którzy w tej chwili przeglądają witrynę. Liczba sesji współbieżnych jest zwykle nieco większa, ponieważ niektóre z nich są w trakcie wygaszania, co wydłuża ś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ń.
Jest to liczba gniazd TCP/IP otwartych na porcie serwera 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ł do innej strony. Zmniejsza to liczbę żądań otwierania nowych połączeń TCP/IP na sekundę. Limity czasu dla tych połączeń różnią się w zależności od przeglądarki, od 60 sekund do nigdy nie zamykaj. Serwer może również automatycznie zamykać połączenia po pewnym okresie braku aktywności. W przypadku serwerów WWW z systemem Linux można uzyskać informacje o liczbie równoczesnych połączeń za pomocą tego polecenia: netstat -aenp | grep ":80 |:443 " | wc -l
które możesz wypróbować, jeśli jesteś ciekawy. Niektórzy ludzie nazywają to również "współbieżnymi użytkownikami".
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.
Należy to zrobić dla każdej strony w strumieniu transakcji - policzyć sumę i podzielić przez liczbę stron, aby znaleźć średnią liczbę żądań HTTP dla każdej strony (numer 3) na naszej liście.
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 jest sześć stron, czyli 1), oraz że średni czas transakcji wynosi pięć minut, czyli 2). Załóżmy, że w przypadku 3) na każdą stronę przypada 36 żądań HTTP, a czas przetwarzania każdego żądania HTTP przez serwer wynosi pół sekundy, czyli 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 strony - to z kolei zwiększa liczbę nowych odwiedzających na minutę, jaką może obsłużyć serwer.
Przekonasz się również, że nie wszystkie strony wymagają tyle samo czasu na ukończenie. Najdłużej trwa przeszukiwanie bazy danych, zapytania do wyszukiwarki i aktualizacje, dlatego gdzieś w procesie pojawi się wąskie gardło, w którym ludzie będą się gromadzić, czekając na przetworzenie danych karty kredytowej i zapisanie zamówienia lub na sprawdzenie dostępności. Każdy przepływ transakcji ma swój najwolniejszy krok, więc zawsze gdzieś jest wąskie gardło. W takim przypadku należy ustawić Queue Rate na tyle nisko, aby serwer mógł obsłużyć wystarczającą liczbę osób jednocześnie na najwolniejszym etapie procesu, tak aby ludzie się tam nie gromadzili. W przeciwnym razie serwer może dosłownie stanąć w miejscu.
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 w czasie spowolnienia lub szczytu ruchu nie jest zadaniem dla osób o słabym sercu. Najlepszą rzeczą do zrobienia jest przeprowadzenie prawidłowego testu obciążeniowego, z "fałszywymi" klientami, którzy faktycznie przechodzą przez proces zamówienia podczas testu obciążeniowego, dokładnie tak, jak 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, jakie widzisz w prawdziwym życiu, i obserwuj obciążenie procesora, przepustowość IO i czasy odpowiedzi w miarę zwiększania liczby wirtualnych odwiedzających. Do tego celu można użyć Apache JMeter (my lubimy też K6 dla lżejszych obciążeń lub wolniejszych maszyn), ale niezależnie od tego, jakiego narzędzia użyjesz, naśladowanie zachowania każdego użytkownika w dokładnie taki sam sposób jest czasochłonne i trudne (zwłaszcza z uwagi na złożoność buforowania). Nawet w takim przypadku należy wziąć swoje liczby i zmniejszyć je o połowę.
W przeciwnym razie należy zachować ostrożność.
Za pomocą portalu Queue-Fair możesz w każdej chwili łatwo zmienić wskaźnik kolejki dla każdej kolejki Queue-Fair. Zacznij od 10 odwiedzających na minutę lub swojego tempa transakcji w bardziej normalnym dniu, sprawdź, jak to będzie przez chwilę po tym, jak bilety trafią do sprzedaży, i 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, podwoić tę wartość, poczekać trochę i powtórzyć. Wkrótce znajdziesz rzeczywistą szybkość, której potrzebujesz podczas tego "równoważenia obciążenia" (widzisz, co 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.
Dlatego nie należy forsować serwerów bardziej, niż jest to konieczne. Osiągnięcie ostatnich 20% przepustowości zwykle nie jest warte ryzyka. Jeśli wielkość kolejki pokazywana w portalu Queue-Fair (żółta liczba i linia oczekiwania na wykresach) zmniejsza się lub nawet rośnie wolniej, minuta po minucie, a pokazywany czas oczekiwania wynosi 50 minut lub mniej, to znaczy, że zamówienia są przetwarzane wystarczająco szybko i kolejka w końcu opróżni się i przestanie pokazywać strony kolejki automatycznie, bez konieczności robienia czegokolwiek przez użytkownika i bez konieczności mówienia szefowi, że zbyt mocno naciskał i ją zepsuł. Osiągniesz to w końcu, o ile szybkość przesuwania się przedniej części kolejki będzie większa niż liczba dołączeń co minutę (obie te wartości są widoczne w portalu Queue-Fair) - punkt zwrotny następuje zwykle po co najmniej kilku minutach każdego wydarzenia. Jeśli sprzedajesz produkt o ograniczonej ilości, prawdopodobnie wyprzedasz go przed osiągnięciem punktu zwrotnego.
Dobra wiadomość jest taka, że jeśli przez przypadek ustawisz zbyt wysoki wskaźnik kolejki i twoje serwery się zatną, Queue-Fair pomoże ci szybko wrócić do pracy - wystarczy, że wstrzymasz kolejkę do czasu, aż twoje serwery będą gotowe do ponownej obsługi odwiedzających. W trybie wstrzymania osoby znajdujące się w kolejce widzą specjalną stronę wstrzymania, którą można zaprojektować przed wydarzeniem online. Nikt nie zostanie przepuszczony z przodu kolejki, gdy jest ona wstrzymana, ale nowi odwiedzający wciąż mogą dołączyć do kolejki z tyłu, aby zostać umieszczeni w niej sprawiedliwie, 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 bardzo niskiego wskaźnika kolejki, zwłaszcza jeśli zaktualizujesz ją, aby poinformować odwiedzających, kiedy spodziewasz się ponownego otwarcia kolejki, co można łatwo zrobić za pomocą edytora stron portalu, nawet jeśli w kolejce są już setki tysięcy osób - a w trybie wstrzymania możesz nawet przepuszczać ich pojedynczo za pomocą unikalnego przycisku Queue-Fair Admit One, jeśli musisz, dopóki system nie odzyska sprawności.
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?
Pamiętaj, że zawsze lepiej być bezpiecznym niż żałować.
