Stabilność a wydajność, czy musisz wybierać?

Stabilność a wydajność — jak myślisz, czy musisz wybierać? Czy te pojęcia są równoznaczne? A może jedno zależy od drugiego? Pierwsze pojęcie kojarzy się z efektywnością, a drugie z bezpieczeństwem. Przeczytaj artykuł i dowiedz się, czy w biznesie naprawdę musisz wybierać, aby zapewnić Twoim systemom ciągłość działania. Na początku spróbujmy wyjaśnić oba terminy, używając języka i przykładów z naszego poletka…

Wydajność

Wydajność rozumiemy jako efektywne korzystanie z systemu. Składają się na nią elementy takie jak: czas wykonywania poszczególnych procesów, responsywność poszczególnych ekranów/kontrolek z punktu widzenia użytkownika, odpowiedzi całego systemu, przetwarzania zadań serwera, kwestia wydajności bazy danych i ewentualnego spowolnienia w czasie. Na przykład, jeśli pewne raporty lub operacje, które z natury wykonywały się dość długo, z czasem tworzą się jeszcze wolniej, to mamy do czynienia z problemem wydajnościowym.

Wolne działanie systemu, czy wybranych procesów, często pojawiające się timeouty, odpowiedzi HTTP 500 czy 502, brak możliwości zakończenia wybranych operacji — to właśnie pierwsze zapowiedzi różnorakich komplikacji związanych z wydajnością. Bardzo częstym problem jest również nadmierne obciążenie bazy danych. Tymczasem, jeśli któraś operacja trwa zbyt długo, to można uznać, że się nie zakończyła.

Szukając możliwych rozwiązań, przede wszystkim musimy zacząć od analizy danych pochodzących z diagnozowanych oraz monitorowanych obszarów, takich jak np.: bazy danych, pamięci, przestrzenie dyskowe, logi aplikacyjne i serwerowe. Zanim zdiagnozujemy jakikolwiek problem, musimy wiedzieć, gdzie go szukać.

Stabilność

Stabilność jest pewną konsekwencją wydajności, ale również niewykrytych błędów w systemie bądź infrastrukturze. Rozumiemy ją jako dostępność oraz bezawaryjność naszego systemu. W myśl tego, jeśli system działa wydajnie, to znaczy, że działa dobrze; natomiast z systemu, który nie działa stabilnie, w zasadzie nie da się korzystać.

Na przykład dłuższe niż zwykle przerwy w działaniu systemu, obniżają jego wydajność poniżej akceptowalnego poziomu. System nadal działa, ale jego używanie jest uciążliwe i nieefektywne. Jeśli dodatkowo przerwy w działaniu pojawiają się losowo, to mówimy, że system nie działa stabilnie. Zazwyczaj problemy nie są losowe, a wynikają z konkretnych okoliczności. W tym przypadku także podstawą do rozwiązania problemu będzie zebranie danych i analiza okoliczności odpowiedzialnych za ten stan. Tym, co zaburza stabilność systemu, może być również tendencja do rozbudowywania poprawnie działających od lat funkcjonalności lub mechanizmów. Skoro zawsze działały, to nikt nie spodziewa się, że dodanie kolejnych elementów wpłynie na utratę stabilności aplikacji.

Dlatego warto w takich przypadkach zachować czujność a przede wszystkim dobrze zaplanować testy regresji, aby dobrze przetestować zmieniane obszary systemu. W przypadku, gdy nie jesteśmy w stanie wykonać pełnych testów regresji, warto przemyśleć czy wartość biznesowa danej zmiany kompensuje ryzyko poprawnego działania naszego systemu.

Stabilność a wydajność. Przykłady z życia

Zajmujemy się od lat wieloma systemami naszych Klientów, ale nigdy nie spotkaliśmy organizacji, w której coś by nas nie zaskoczyło. Niespodzianki bywają różne. Co ciekawe, nadal częstszą i bardziej dotkliwą jest brak miejsca w przestrzeni dyskowej. To prawie zawsze kończy się poważnym problemem produkcyjnym. Aplikacja po prostu przestaje działać. System nie może logować, blokuje się przy próbie zapisu, a w konsekwencji totalnie zawiesza.

Bazy danych

Kolejnym bagatelizowanym obszarem, są bazy danych. Tutaj jednym z podstawowych niedociągnięć są braki indeksów. Często programiści, przygotowując aplikację, wykonują podstawowe testy w ramach aplikacji uruchomionej w jej pierwszych tygodniach lub miesiącach pracy. Wszystko działa wspaniale do czasu, gdy pewne procesy nagle zwalniają. Weźmy typowy przypadek z życia, kiedy to brakuje indeksu na pewnym zestawie kolumn. Przy podstawowych wywołaniach – kluczach i kolumnach mamy założone indeksy i wszystko będzie ok. Natomiast wchodząc w szczegóły, biorąc inne zapytania, pojawiają się problemy. Zazwyczaj tego typu defekt w którymś momencie ujawni się w każdym systemie, nawet tym najlepiej przygotowanym. Bardzo często te problemy nie wychodzą na testach, ponieważ na tym etapie baza danych zawiera tylko niewielką ilość danych testowych. W momencie, gdy wprowadzimy do niej dużo danych produkcyjnych, problemy bardzo szybko się ujawniają w różnych obszarach.

Ilość danych

Innym przykładem nawiązującym do tematu ilości wolnej przestrzeni czy poziomu jej zapełnienia będzie gwałtowny przyrost danych. Jeżeli jedna czy druga tabela mocno „puchnie”, system również zwalnia. Tu rozwiązana mogą być dwa. Po pierwsze – optymalizacja tych procesów na poziomie bazy danych. Bywa jednak, że nie trzeba posuwać się aż tak daleko. Wielokrotnie spotkaliśmy się z sytuacją, gdy po analizie zawartości, okazało się, że w zasadzie część danych jest niepotrzebna lub nieużywana, więc można je usunąć lub zarchiwizować.

Działa, nie działa, działa…

Niedawno spotkaliśmy się z sytuacją, gdy system po prostu zawieszał się, ale w całkowicie losowych momentach. Najczęściej konieczny był restart. Po analizie okazało się, że problemów było kilka. Nakładały się na siebie i dopiero wtedy, gdy wystąpiły wszystkie naraz (od sytuacji większego obciążenia, poprzez użycie konkretnych funkcjonalności systemu), powodowało to zaburzenie stabilności. W każdym innym przypadku system działał prawidłowo. Wyłapanie tych zależności było najtrudniejsze. Dopiero zapięcie dodatkowych monitoringów, dodanie dodatkowego logowania spowodowało, że byliśmy w stanie zlokalizować i przywrócić stan prawidłowy.

Batche w ciągu dnia

Na koniec jeszcze o pokusach. Jedną z nich puszczanie procesów batchowych także w ciągu dnia. Zazwyczaj z powodu braku czasu lub innych bardziej, lub mniej usprawiedliwionych okoliczności. Decydujemy się to robić, choć wiemy, że nie są one przeznaczone do pracy w okresie, gdy system jest używany przez „biznes”. Konsekwencje są oczywiste. Dochodzi do dużej niestabilności systemu i poważnych problemów wydajnościowych. W konsekwencji do niezadowolenia użytkowników z systemu i w takich przypadkach trudno im się dziwić. Często stosowany model jest taki, że przetwarzanie tego typu stosuje się w nocy czy w weekendy – trochę jak backupy. Jeśli muszą działać w trakcie normalnej pracy systemu, warto wydzielić je na odrębne instancje aplikacyjne, by zminimalizować ich wpływ na instancje ruchowe.

Stabilność a wydajność, razem czy osobno?

Jeśli chcemy utrzymać wydajność, optymalizujmy najczęstsze, najdłuższe operacje, czy, z punktu widzenia bazy danych, te najbardziej kosztowne. Diagnozujmy, gdzie pojawiają się problemy wydajnościowe i na tych obszarach skupmy się najmocniej. W przypadku problemów, które występują bardzo losowo i gdzie trudno zlokalizować przyczynę, musimy podjąć kroki związane z dokładniejszym monitorowaniem lub rozszerzeniem logowania. W przypadku systemów, które operują bezpośrednio na bazach danych, zdecydowana większość kłopotów z wydajnością będzie zlokalizowana po stronie bazy danych.

Stabilność działania może zależeć od wielu czynników — błędów w aplikacji, określonych warunków pracy czy nałożenia się kilku pozornie niezwiązanych ze sobą czynników. Zawsze w takim przypadku potrzebujemy zgromadzić dane i każdy problem traktować indywidualnie.

W tym miejscu należy zadać sobie pytanie – co wybrać — wydajność systemu czy jego stabilność? My proponujemy inne rozwiązanie. Zamiast wybierać jaki rodzaj problemów preferujemy lepiej zapobiegać im wszystkim. Lepiej zainwestować w kompleksową obsługę systemu, a wydajność i stabilność otrzymasz w pakiecie jako wynik naszych profilaktycznych działań.