Liczba godzin przetwarzania
Pytanie o liczbę godzin w kontekście IT może się wydawać dziwne 😕.
Typowemu użytkownikowi rozwiązań informatycznych z czasem kojarzy się głównie: odpowiedz systemu w 3 s.
Spisując wymagania niefunkcjonalne dla rozwiązania, o ile to robimy – to wskazujemy, że coś ma działać szybko.
Czasami nawet podajemy te przysłowiowe 3 sekundy,.
Jednakże w rozwiązaniach informatycznych są procesy/zadania, których wprawdzie użytkownik bezpośrednio nie widzi, ale jednak może zaobserwować ich negatywny wpływ 😳.
Takie procesy zazwyczaj trwają długo, minuty a czasem godziny.
Przykłady takich procesów to:
- backup
- kasowanie historii i czasem jej archiwizacja
- naliczenia różnego rodzaju:
- lista płac
- billing
- raport potwierdzenia sald
- wyszukiwanie zaległości płatniczych
- migracje
- na nowy sprzęt
- przeniesienie danych do nowego rozwiązania
- migracja do chmury
Oczywiście nie są to wszystkie przypadki, ale mam nadzieję iż obrazują one jakie zagadnienie poruszam.
Rodzaje wpływu
Powyżej wypisane przykłady procesów długich mogą mieć wpływ na użytkownika rozwiązania.
Bez wnikania w szczegóły z czego to wynika możemy wyróżnić trzy objawy, które opisze poniżej.
Oczywiście przytoczone rozważania będą ogólne i w szczególnych przypadkach ewentualny negatywny wpływ może być adresowany na różne sposoby i zazwyczaj ma to znaczący wpływ na koszty całości rozwiązania 🙁.
Ponieważ bogactwo różnorodnych sytuacji jest olbrzymie, dlatego ograniczę się jedynie do wskazania głównych faktorów, które powinniśmy brać pod uwagę.
Spadek wydajności
Podstawową przyczyną spadku wydajności rozwiązania w przypadku procesów trwających długi jest konkurencja w dostępnie do zasobów.
Procesy długotrwałe pracują na dużych zestawach danych, czyli dużo czytają i też trochę zapisują, DUŻOOO więcej w stosunku do pojedynczych transakcji 😛.
Kiedyś mówiło się, że te ciężkie procesy będziemy „uruchamiać w nocy”, ale w dobie Internetu pojęcie nocy zmieniło znaczenie.
Obecnie powinniśmy znać profil użycia naszej usługi, aby nie robić w nocy, tylko w okresie minimum użycia, a to mogą być różne godziny.
Najlepiej sprawdza się profil tygodniowy.
Przysłowiową nocą może być 2-8 rano w poniedziałek 😛.
Ograniczenie funkcjonalności
W czasie wykonywania określonego zadnia chcąc zapewnić spójność danych rozwiązanie może ograniczyć/wyłączyć funkcjonalność dokonywania zmian w danych źródłowych.
Jest to jeden z przykładów ograniczenia funkcjonalności dla użytkowników w związku z wykonywaniem jakiegoś procesu naliczającego.
Oczywiście powinno to być zgodne z założeniami wymagań, czy będą to wymagani funkcjonalne czy niefunkcjonalne to sprawa wtórna.
Przykład to zamykanie miesiąca w systemie finansowym lub naliczanie listy płac –
Nie możemy wówczas modyfikować danych 🙁.
Innym przykładem jest rozciąganie w czasie czyli dzielenie na kroki zdarzeń.
Przykładem takiego podejścia jest w zakupach internetowych podzielenie zamówienia na dwa kroki: przyjęto zamówienie i potwierdzenie realizacji.
Pozwala to, aby nie robić jakiegoś skomplikowanego technicznie rozwiązania zapewniającego obsługę zdarzenia,
kilku klientów zamówi i będzie oczekiwać na dostarczenie XYZ, które jest w liczbie 1 sztuka w magazynie 😛.
Oczywistym jest, że musi to być zdefiniowane lub do-definiowane w trakcie projektu 😛.
Niedostępność
Sporadycznie, ale jednak trzeba wykonać zadania na systemie informatycznym, które powodują konieczność jego całkowitego wyłączenia.
Obecnie zdarza się to rzadko, lecz co jakiś czas ma to miejsce.
Przykłady takich operacji to upgrade do nowszej wersji lub zmiana całego systemu.
W latach dziewięćdziesiątych ubiegłego wieku często wymóg utworzenia spójnego backupu/kopi powodował konieczność wyłączenia systemu.
Obecnie ta metoda jest stosowana przy tworzeniu tak zwanej zimnej kopii.
Przygotowując się do takiej operacji służby IT starają się tak zorganizować ten proces, aby faktyczny downtime (niedostępność) była jak najkrótsza, ale mimo akceptacji dużych kosztów, zawsze to trochę będzie trwało.
Godziny z tytułu
- Każda operacja wykonywana nawet przez najszybszy komputer zajmuje trochę czasu.
- Przetwarzanie w kontekście, czyli z uwzględnieniem dodatkowych źródeł danych trwa tym dłużej im więcej źródeł i im są dalej
- Przesłanie danych zajmuje czas w zależności od ilości danych i szybkości komunikacji
- Zapis wyników może być zatrzymany na pewien czas z powodu zapisu przez inny proces, tak zwane blokowania (locks)
To oczywiste oczywistości zarówno dla pojedynczej transakcji biznesowej, jak również dla przetwarzania masowego, czyli wielu transakcji 🙂.
Konsekwencją tego jest znacznie różny od zera czas przetwarzania pojedynczego zdarzenia biznesowego.
Dla pojedynczej transakcji na interface użytkownika przyjmujemy, że jest OK poniżej 3 sekund.
Jednakże gdy mamy zrobić tysiąc takich operacji to czas trwania to 3 000s, czyli mała godzina.
Dla 10 tyś zdarzeń to już ponad 8 godzin i 20 min 😀.
Oczywiście można to procesować wielowątkowo, ale zazwyczaj powoduje to wzrost czasu przetwarzania pojedynczej transakcji i wymaga większego serwera, czyli więcej rdzeni.
Jak Firma używa dużych serwerów to prawdopodobnie nie procesuje tysięcy transakcji, ale raczej dziesiątki a może nawet setki tysięcy.
Podsumowując, procesy masowego przetwarzania, często zwanego batch`owym trwają długo.
A jak zostało to źle zaprojektowane to mogą zaburzać normalne użytkowanie systemu przez wiele godzin.
Osobiście spotkałem się z projektem w którym przy założeniu niedostępności przez weekend (poniżej 36 godzin) prosty rachunek: liczba kont razy 3 s podzielony na 20 wątków (duże ryzyko blokowań – czyli zamiast 3s dużo więcej) dawał ok. 80h przetwarzania dla jednego kroku, a miało ich być 5 🙁.
Często ten mankament odkrywany jest na bardzo późnym etapie projektu lub wręcz w czasie działania rozwiązania wraz ze wzrostem liczby użytkowników/klientów.
Taki przykład klęski urodzaju 🙂 / 🙁.