SKR kontra SMS

Jak wiadomo, systemy informatyczne zajmują się realizacją zadań. Wykonanie każdego zadania wymaga od systemu zaangażowania pewnych zasobów. Każdy system posiada pewne określone i skończone zasoby. Przy tych założeniach łatwo domyślić się, że całkiem realna jest sytuacja, kiedy zasoby systemu nie wystarczą do realizacji takiej ilości zadań, jaka pojawia się na jego wejściu. Chciałbym dzisiaj zająć się tym, jak ocenić wpływ konkretnych zadań, które realizuje system, na zużycie zasobów, co pozwoliłoby sporządzić pełny bilans obciążeniowy.

Rozważania oprę na analizie zachowań dwóch twórców pewnego systemu, każdy z nich właśnie ukończył implementację jednej funkcji realizującej jedno konkretne zadanie. Zachodzi oczywiście pytanie o wpływ tych implementacji na działanie systemu, która jest „dobra” i nie wpływa, a która jest „zła” i wpływa negatywnie. Analizować będziemy czas trwania zadań, bilansując go z zasobami procesorowymi systemu, inne zasoby dla uproszczenia pominiemy.

Implementacja twórcy A jednostkowo trwa 170ms, jest to funkcja używana przez handlowców, handlowcy są operatorami systemu i zajmują się przyjmowaniem zamówień, handlowców jest ok. 100, pracują 8 godzin dziennie w tych samych, standardowych godzinach pracy. Średnio jeden handlowiec przyjmuje 80 zamówień dziennie, zamówienia mają po ok. 7 pozycji, w bieżącej pracy handlowcy będą używać tej funkcji prawie przy każdej pozycji zamówienia, powiedzmy, że będzie to 80% przypadków.

Implementacja twórcy B jednostkowo trwa ~ 1 min i 15 s, jest to raport używany przez kierowników działu sprzedaży, działów sprzedaży jest 4, kierownicy tworzą kilkanaście takich raportów (załóżmy, że 12) pod koniec każdego miesiąca, miesiąc rozumiemy jako 30 dni.

Policzmy dla każdej z implementacji Sumaryczny Koszt Realizacji:

SKR = JKO * OIW

gdzie:
JKO – Jednostkowy Koszt Realizacji
OIW  – Okresowa Ilość Wywołań

Podstawiając dane, otrzymujemy:

SKR(A) = 0,170s * (100 * 80 * 7 * 0,8) = 2,11 godziny
SKR(B) = 75s * (4 * 12 * 1/30) = 0,03 godziny

Konfrontując to z Sumaryczną Mocą Systemu definiowaną jako:

SMS = IR * OK

gdzie
IR – Ilość dostępnych Rdzeni (w naszym przypadku 6 rdzeni)
OK – Okres, w którym system jest dostępny (w naszym przypadku 8godzin)

Podstawiając dane, otrzymujemy:

SMS = 6 rdzeni * 8 godzin = 48

Co pozwala na obliczyć procentową postać SKR dla obu zadań, czyli:

SKR(A) = 2,11 / 48 * 100% = 4,40%
SKR(B) = 0,03 / 48 * 100% = 0,06%

Wyniki mówią same za siebie, Sumaryczny Koszt Realizacji zadania A jest ogromny, w skali całego systemu jest to na tyle duża wartość, że warto, aby Twórca implementacji jeszcze raz zabrał się do pracy i spróbował wykonać swoją pracę lepiej. SKE dla zadania B jest na tyle mały, że aktualna implementacja, choć jak widać z czasu trwania nie najlepsza, pod tym względem nie wymaga żadnych działań.

Wszystko to prawda, ale czy cała? Przy naszych rozważaniach nie wolno skupiać się wyłącznie na SKR, wskaźnik ten pokazuje średnią, statystyczną wartość, jednak zastanówmy się co stanie się w opisywanym przykładzie pod koniec miesiąca. Wszyscy kierownicy tego samego dnia ok godziny 14:00 (wiemy to, bo o 15:00 mają zebranie, na którym prezentują wyniki analiz) będą chcieli zrealizować swoje zadania, kierowników jest 4, a dostępnych rdzeni mamy 6, w najbardziej pesymistycznym przypadku ich działania spowodują chwilowe zmniejszenie zasobów systemu o 66% do poziomu 34%. Z wcześniejszych analiz wszystkich innych zadań wiemy, że łączna suma ich SKR wynosi 72,6%, tyle mocy systemu jest statystycznie konsumowane na obsługę typowych zadań.

W oczywisty sposób widzimy, że: 34% < 72,6% co oznacza, że nasi sympatyczni kierownicy swoimi zadaniami doprowadziliby do chwilowego wyczerpania zasobów systemu.

Jak temu zaradzić? Poza oczywistą próbą optymalizacji zadania B są przynajmniej trzy metody:

Limitowanie – limitowanie liczby jednocześnie wykonywanych raportów, naturalnie może ograniczyć liczbę rdzeni angażowanych w ich generowanie (identyfikacja i limitowanie zadań długotrwałych, pisałem już o tym w którymś z wcześniejszych wpisów)
Kolejkowanie – ustawianie zadań realizacji raportów w kolejkę obsługiwaną szeregowo, pozwala ograniczyć liczbę rdzeni, przy bardziej wygodnym sposobie obsługi.
Planowanie – planowanie zadań realizacji raportów rozłożone w czasie, tak że wykonują się one w okresie, kiedy system nie jest obciążony, a wyniki dostarczane są osobom zainteresowanym, np. w postaci gotowych dokumentów PDF.

Na koniec każdemu twórcy, który myśli sobie „te kilka milisekund … nikt nawet nie zauważy” polecam liczenie SKR dla wszystkich realizowanych implementacji oraz świadome i ostrożne konsumowanie zasobów systemu.