Oddając do użytku skończoną platformę, powinieneś znać jej możliwości, wiedzieć jaki jest w stanie obsłużyć ruch bez palenia procesorów, kart sieciowych czy dysków, znać miejsca potencjalnie podatne na “wąskie gardła”, wiedzieć czy i gdzie znajduję się z angielskiego tak ładnie nazywany SPoF (Single Point of Failure), wiedzieć o niej tak dużo jak się da. Oczywiście najlepiej byłoby gdyby, platforma była łatwo i bez ograniczeń skalowalna, bezawaryjna, bezobsługowa, samowystarczalna i robiła jeszcze kawę… ale na szczęście jesteśmy realistami i wiemy, że takie w naturze zbyt często nie występują, a przynajmniej nie powstały od razu, tylko były dopieszczane długimi godzinami, tak więc na ma co się zniechęcać, tylko trzeba usiąść i pomyśleć co zrobić, żeby mogło być lepiej, a od czego zacząć? Od naszych “ulubionych” testów.
Wszystko ok… tylko, że platforma którą zrobiłeś nie daje się łatwo przetestować, jest to rozwiązanie szyte na miarę, nie istnieje żadne automagiczne narzędzie (przetestuj_moja_platforme.sh) które uruchomione coś przemieli, pomieli i wypluje jednoznaczny wynik, tak to zła wiadomość… Yhyy, ja też zawsze szukam wymówek, ale nie oszukujmy się, co stoi na przeszkodzie by opierając się nawet na istniejących rozwiązaniach spróbować stworzyć własne? Nie mówię tutaj o napisaniu swojego jMeter’a, czy ab… ale bardziej o odpowiednim zestawieniu kilku prostych i dobrze nam znanych aplikacji. Czasami okaże się, że wystarczy (time, cat, netcat). A jeśli potrafisz szukać informacji (zakładam, że tak) to znajdziesz przykłady skryptów np. w Perlu, które tworzą socket, wysyłają coś i pobierają odpowiedź, ubierz to w pętlę, dodaj forkowanie, dorzuć jakiegoś if’a całość opakuj funkcjami time i już masz proste narzędzie do testowania, nie przejmuj się tym, że nie jest to rozwiązanie profesjonalne (who cares?), ważne, że dzięki niemu będziesz posiadał informację, której jeszcze chwilę temu nie miałeś. Podejdź do całości procesu w ten sposób, że lepiej jest posiadać wyniki obarczone nawet sporym błędem niż żadne. Orientacyjne wartości też będą dla Ciebie wskazówką, dodatkowo podczas jednego testu, może okazać się, że poznasz wyniki dla zupełnie innego, np. testując aplikację uda Ci się tak obciążyć serwer, że pojawi się problem z dostępem do dysku lub skończy się pamięć.
Wszystkie wyniki zapisuj, otwórz plik tekstowy, kopiuj i wklejaj wszystko do niego, argumenty wywołania, zbędne informacje, po prostu wszystko jak leci… Może Ci się wydawać, że zapamiętasz część danych, ale po setnym uruchomieniu wszystko ma prawo się pomieszać. Jeśli nazbierasz wiele próbek to spróbuj zrobić wykresy z tego, jeśli znasz rrdtool to użyj go, jeśli tworzenie baz RRD to czarna magia dla Ciebie, to przenieś wszystkie dane do arkusza kalkulacyjnego i zrób w nim wykres, to nie jest żaden obciach, że używasz OpenOffice, czy Excel, bądź skuteczny, a nie “poprawny”. Zauważysz, że czasami dopiero po zobrazowaniu dużej ilości zebranych danych widać, że aplikacja działa doskonale, ale dla 25 użytkowników, natomiast powyżej tej liczby wydajność spada dwukrotnie. Nie wszystko widać od razu.
Testuj tak by jak najbardziej możliwie odwzorować realne warunki pracy, np. jeśli chcesz sprawdzić swoje dyski na które będą lądowały ładowane zdjęcia od użytkowników, to nie kopiuj na nie filmów, nie licz ile czasu to zajmie, kopiuj dużo małych plików, zbliżonych rozmiarem do zdjęć, bo jeśli nie zachowasz podczas testów w miarę realnego odwzorowania sposoby pracy, to Twoje wyniki nie są nic warte. Zawsze staraj się testować w taki sposób, by jak najbardziej możliwie zbliżyć się do realnej pracy systemu.
Po co to wszystko? Nie dlatego, że ktoś wcześniej czy później poprosi Cię o te dane, ale po prostu dla własnego spokoju, by wiedzieć, że nie stworzyło się potwora, do którego będziemy musieli przyszywać kolejną rękę wraz z dodaniem funkcjonalności. Musimy wyrobić w sobie nawyk, by znać dość dobrze możliwości systemów które uruchamiamy, bez tych podstawowych informacji nie możemy skutecznie nimi zarządzać, ponieważ taka administracja sprowadza się do usuwania awarii a nie do zapobiegania im, a znając ograniczenia, nawet nie dokładne, ale przybliżone, da to nam informację po jakim czasie będziemy musieli zastanowić się nad dokupieniem kolejnego serwera, lub wykonaniem optymalizacji. Wszystkie zebrane informacje powinny być przede wszystkim wykorzystywane przy monitorowaniu usług, jeśli sprawdzasz czy usługa dana działa, to sprawdź przy okazji jak wygląda jej wykorzystanie, porównaj to z wynikami testów i będziesz wiedział czy to właśnie już trzeba pisać zamówienie na serwer, czy dopiero po wakacjach… ;-)
Czasami naprawdę warto wykonać testy, chociażby po to by kupić sobie spokój, wiem, że to nie jest najciekawsze zajęcie, ale lepiej poświęcić trochę czasu na testy i wiedzieć co się dzieje, niż później w stresie w trybie natychmiastowym podejmować decyzje, rzadko kiedy słuszne…
- przepraszam za przynudzanie ;-)
Podobne wpisy:
oceń artykuł (3 gł., średnia: 4,67)
Dziekujemy za glos. ...Podaj dalej:
Cóż za mentorski tom. Powinieneś założyć anglojęzyczny blog, a następnie wydać superwielomilionowy bestseller ‘Jak mieć kasę nie pracując’ ‘Bogaty sysadmin, biedny sysadmin’.
A tak w ogóle, to jasne, że warto testować :)