Jak sprawdzić ile ruchu wytrzyma moja strona? Odpowiedź jest prosta: testy wydajnościowe. Dziś już nie wystarczy wygrać przetarg, pokonać swą ofertą konkurencję i stworzyć świetny projekt serwisu na potrzeby dużej kampanii marketingowej. Na drodze do prawdziwego sukcesu i szczęścia właściciela serwisu stoi jeszcze wydajność strony – ten newralgiczny element, który sprawia, że serwis jest dostępny i mogą z niego korzystać tysiące użytkowników równocześnie.

 

Serwis startuje, coś nie działa, wolno działa, powoli się ładuje. Kto jest winny?

 

Klient?

Podał jakieś dane odnośnie planowanego ruchu? Pewnie nie, albo były one dalekie od rzeczywistości. Może podał mediaplan kampanii reklamowej? Fajnie, ale kto potrafi przeliczyć ilość odsłon w serwisie, wygenerowanych przez mailing do miliona odbiorców Onetu albo 30mln odsłon banerów na Wirtualnej? Mailing będzie ciekawy? Będą klikać? A jak klikną to zamkną od razu stronę, czy dopiero po kolejnych 10 klikach? Wszystko to estymacje.  Jeśli jednak klient miał wiedzę i podał te dane, albo znał je z doświadczenia, to jeśli serwis padł przed ich osiągnięciem, to winnego szukamy dalej. W przeciwnym wypadku to klient bierze odpowiedzialność za to, że wszyscy dalej „wróżyli z fusów”. Można też oczywiście przyjąć też czarny scenariusz, ale to będzie kosztowne, zasoby serwerowe będą z zapasem – a im większym, tym drożej. Można też zdać się na doświadczenie Hostersów w wyborze rozwiązania – wtedy będziemy mieli pewność, że jeśli Developer wykona swoją pracę dobrze, to serwis będzie działać odpowiednio szybko.

 

Agencja?

No jasne, że jest winna – zawsze jest przed klientem. Powiedzmy, że znała jakiekolwiek dane o ruchu – jak to przełożyć na serwis, ktoś sprawdził ile na wybranych zasobach wytrzyma serwis? Przecież jest tyle elementów, może któryś z nich odpowiada za 90% problemu i warto go wykryć i wyłapać? Agencja przekazała jakieś wytyczne firmie hostingowej? Ktoś obiecał, że to tyle wytrzyma? Jeśli tak, to na jakiej podstawie. Często kończy się to przepychanką, że baza dociążona, że ciężkie zapytania, strona dużo waży itp.

 

Programiści?

Wielce wątpliwe, żeby jakiś programista zadręczał się, jak duży ruch powinien wytrzymać serwis, gdy go kodował. Był projekt i deadline, raczej odbyło się bez rozczulania nad wydajnością, chyba że już wcześniej zaliczono wpadki i po prostu trzeba było mieć się na baczności. W najgorszym razie można zwalić winę na serwer – że jest „źle skonfigurowany”, etc.

 

Firma hostingowa?

Ona jest zawsze winna, bo przecież to u niej padło. Tylko czy ktoś w ogóle projektował jakieś rozwiązanie, czy „wylosowano” jakiś hosting, bo taki był budżet, albo przyjęto na podstawie grubości lodu na Antarktydzie w 1964 roku, że serwis odwiedzi max 1000 osób dziennie? No i jest zawsze opcja zwalenia odpowiedzialności na Developerów, że kiepski kod, niewydajny, etc. 😉

 

Jak więc sprawdzić ile ruchu wytrzyma serwis?

Zwykle nie da się oszacować takiego zapotrzebowania na infrastrukturę – nie ma danych i za dużo jest czynników, które mają na to wpływ. Począwszy od wydajności aplikacji/serwisu poprzez konfigurację serwerów, architekturę aplikacji i oprogramowania serwerów aż po nieprzewidywalny ruch czy zachowania użytkowników, albo i niespodziewaną popularność serwisu.

Dużo pytań i jeszcze więcej potencjalnych winnych. Kłopot w tym, że właściciela serwisu to kompletnie nie obchodzi, bo to on stracił klientów i wizerunek. A tak naprawdę jest bardzo prosta metoda, aby się dowiedzieć, na co możemy liczyć. Trzeba sprawdzić, jak potencjalni użytkownicy obciążą serwis i ile strona jest w stanie wytrzymać. Służą do tego testy wydajnościowe, zwane także testami obciążeniowymi.

 

Sprawdzamy wydajność serwisu – testy wydajnościowe

Idea testów wydajnościowych polega na symulacji ruchu i zachowań prawdziwych odwiedzających za pomocą specjalnego oprogramowania i infrastruktury. Aby wykonać taki test trzeba przygotować scenariusze testowe, czyli listę czynności, jakie wykonuje na stronie potencjalny odwiedzający. Stworzyć je można na bazie znanych danych np. z Google Analytics, dot. ścieżek zachowań użytkowników lub stworzyć taki scenariusz na bazie własnych oczekiwań. Można też sprawdzić na kilku znajomych z pracy, co robią w serwisie, który właśnie tworzymy. Scenariusz może też zawierać czynności, podejrzane o największe obciążenia serwisu. Scenariuszy może być wiele. Tak opracowany scenariusz trzeba zaprogramować w środowisku symulującym użytkowników, a następnie uruchomić wielu agentów, którzy będą takie scenariusze wykonywać na stronie. Specjalistyczne oprogramowanie pozwala stworzyć wiele serwerów i z ich poziomu uruchomić bardzo wielu agentów – nawet tysiące osób na sekundę. Oczywiście taki test powinien możliwie najlepiej odpowiadać rzeczywistości. Przy okazji – do takich testów idealnie wręcz nadaje się chmura. A test warto zrobić zanim serwis ruszy, albo na infrastrukturze, która niekoniecznie obsługuje serwis produkcyjny (testowej).

Wynikiem działania takiego testu może być raport, pokazujący jaką liczbę użytkowników serwis był w stanie obsłużyć, gdzie np. kryterium był czas załadowania strony nie dłuższy niż określona wartość.

Możemy sprawdzić wiele sytuacji:

  • czy serwis wytrzyma i jak zniesie ilość odwiedzin, którą podał klient,
  • jaka jest graniczna wartość odwiedzin dla obecnej infrastruktury,
  • gdzie mamy słabe punkty, co powoduje, że serwis obciąża serwer (analiza obciążenia serwerów).

 

Nawet jeśli nie mamy wytycznych co do tego, ile serwis ma wytrzymać, to poznanie tej wartości pozwala nam powiedzieć właścicielowi serwisu, że np. serwis wytrzyma 10000 odwiedzin na godzinę, przerzucając w pewnym stopniu odpowiedzialność na niego za stwierdzenie, czy to mało czy dużo. Oczywiście to bardzo trudne, ale ktoś musi podać te wartości, a jedyną osobą, która może to zrobić z pełną odpowiedzialnością jest właściciel serwisu. W rzeczywistości jednak taki raport pozwala zidentyfikować słabe punkty, by następnie je poprawić.

Z doświadczenia Hostersów wynika, że z łatwością można poprawić wydajność serwisu kilkukrotnie. Jeśli nawet nie wprowadzimy poprawek od razu, to przynajmniej mamy jakiś plan i wiedzę, co zrobić jak zacznie się robić „ciasno”. W swojej praktyce spotkaliśmy wiele optymalizacji wykonywanych w ramach analizy „post mortem” (czyli jak już padło), ale też bardzo wiele serwisów udało się uratować poprzez wcześnie wykonane testy i wdrożenie zaleceń. Proces takiej optymalizacji wykonany wspólnie z Developerami pozwala w paru krokach poprawić sytuację. I nie chodzi tu o szukanie winnych – Developer bez informacji od strony serwera niewiele może zrobić, więc to normalne, że takiej informacji potrzebuje. W wielu specyfikacjach serwisów pojawiają się parametry wydajnościowe – czas załadowania, ilość użytkowników itp. Testy wydajnościowe powoli stają się normą, szczególnie wśród e-commerce czy start-upów.

 

Hostersi doradzają, jak zbudować aplikację wydajną i skalowalną oraz wykonują testy wydajnościowe serwisu.

 

Jak sprawdzić ile ruchu wytrzyma moja strona? Co można zrobić z wynikami testu?

Najlepsza opcja jest wtedy, kiedy wykonujący test może obserwować, co się dzieje na serwerach. Gdzie mamy korki i słabe punkty. A że będą, to wiemy niemal na pewno, tak samo jak to, że można je wyeliminować. Czasem dokładając programiście 2h pracy można podnieść wydajność serwisu 100x. Serio. Często przyczyną problemów są banalne błędy i przeoczenia – brak poprawnych indeksów w bazie, włączony tryb debugowania aplikacji, niepoprawny warunek pętli, jakiś limit na serwerze, brak cachowania na serwerze, czy w aplikacji, itp. Oczywiście nie zawsze będzie prosto, czasem błąd jest u podstaw projektowych algorytmów w serwisie, a wtedy zmiany są kosztowne i czasochłonne. Ale takie testy to jedyny wskaźnik powodzenia projektu. Aby móc z całą pewnością powiedzieć, że coś usprawniono, to trzeba to zmierzyć przed i po robieniu usprawnień. Retesty po poprawkach pokażą w liczbach – czarno na białym, czy się poprawiło i o ile. I czy przy okazji nie popsuliśmy czegoś innego. Testy można robić wielokrotnie.

Jeśli chcesz uniknąć problemów z wydajnością serwisu, zgłoś się do nas już na etapie projektu rozwiązania. Doradzimy Ci, jak zbudować aplikację wydajną i skalowalną, a na koniec wykonamy dla Ciebie testy wydajnościowe, abyś wiedział, że możesz spać spokojnie. To, czy użyjemy do tego jednego VPSa, czy rozbudowanej infrastruktury w chmurze będzie zależało już od wielkości projektu i oczekiwań.

Jeśli więc w wytycznych serwisu spotkasz zapis: „serwis powinien umożliwić wykonanie 50 transakcji zakupu na sekundę przy zachowaniu czasu ładowania poniżej 4s” – zapraszamy i pomożemy Ci zweryfikować, czy tak rzeczywiście jest… zanim zrobi to za Ciebie klient. Zapewniamy spokojny sen, a spokojny sen jest bezcenny.

 

 

 

 

Zobacz również:

Dlaczego moja strona wolno się ładuje?
Hosting ecommerce dla sklepu internetowego
Przeniesienie sklepu internetowego do chmury
Infrastruktura serwerowa bez tajemnic. Serwer dedykowany, VPS, czy chmura?
Zarządzenie serwerami i optymalizacja dla Olive.pl
Chmura AWS na czas sprzedaży biletów na koncert Justina Biebera