Zaczynamy od 60ki

Biegacie? Ja biegam, „niezaczęsto”, „niezamocno”, mój rekord to półmaraton w czasie około 2h, wiem, nie ma się czym chwalić. Pamiętam w czasach szkoły podstawowej na tak zwanym WF’ie, mieliśmy biegać na 60 i chyba 1500, dla WF’isty oczywiste było, że zaczynamy od 60ki, a potem robimy długi dystans, wiadomo, to jest lepsze podejście. Niektórzy w pogoni za lepszym czasem próbowali kilka razy tą 60kę przebiec i jak twierdził WF’ista nie miało to wpływu na wynik na później przebiegniętym długim dystansie.

Kontynuując rozważania nad jakością systemów informatycznych w obszarze zapewnienia wydajności, znajduję analogię to tych dawnych WF’owych wydarzeń. Systemy informatyczne też biegają na 60, wtedy kiedy realizują proste krótkie i szybkie zadania, np. dodanie nowego adresu do kontrahenta, potrwa to pewnie kilkanaście ms i gotowe, bez jakiegoś wielkiego obciążenia serwerów, dysków itd. Czasem jednak systemy biegają na 1500, wtedy kiedy realizują ogromnie złożone i kosztowne zadania, np. przygotowanie raportu przekrojowego za znaczny okres przetwarzającego ogromne zbiory danych, może to trwać minuty, angażując procesory, pamięć i kanał dyskowy w znaczącym zakresie.

Jeżeli zmusimy nasz system informatyczny, do jednoczesnej realizacji obu typów zadań, może okazać się, że klika równoczesnych zadań długodystansowych znacząco obniży wydajność systemu, a łatwo sprawdzić, że naprawdę dużo zadań krótkodystansowych co prawda obciąży system, ale będzie się to działo w sposób płynny i będzie można obserwować „eleganckie” skalowanie systemu. Co zatem zrobić? Omówię dwa rozwiązania.

Pierwsze jest bardzo proste. Niech system w operacyjnym obszarze nie biega na 1500! Zadania takie przesuńmy na obszar analityczny, zbudujmy hurtownię danych, zasilmy ją w procesie ETL, dajmy interfejs OLAP, i taki podsystem niech biega na 1500. Szybko okaże się, że po pierwsze dla niego nie jest to 1500 a 100 i że o wiele lepiej radzi sobie z takimi dystansami, bo jest do tego zaprojektowany. Rozwiązanie to działa w obszarze analitycznym, a co z pozostałymi typami długotrwałych zadań?

Drugie rozwiązanie jest w założeniach też bardzo proste. Uznajmy, że system w obszarze operacyjnym może biegać na 1500 ale nie może robić takich „tras” zbyt wiele naraz. Monitorujmy zadania realizowane przez system, rozpoznajmy te długie i stosując jedną z metod kontroli, starajmy się nad tym zapanować. Możemy uznać, że każde zadanie ma określony typ (STANDARD, LONG), zadania standardowe mają limitowany czas trwania np. 10s oraz nielimitowaną ilość, zadania długotrwałe mają limitowany czas trwania np. 5min, i dokładnie określoną ilość jednoczesnych, np. 3. System z takimi założeniami będzie dążył do zapewnienia własnego nieprzerwanego działania, będzie się „bronił” przed złymi zapytaniami, za długimi raportami, nieoptymalnymi algorytmami i zbyt dużą ilością dystansów 1500. Systemy tak skonstruowane osiągają lepsze wyniki w wielu obszarach wydajności a głównie w obszarze odporność przeciążeniowej i odporności przeciążeniowej wstecznej.

Na koniec nadmienię (z radością), że systemy działające na platformie NEXT zakładają stosowanie obu tych rozwiązań.