Biuletyn techniczny. Wzrost wydajności modułu kadrowo-płacowego CDN OPT!MA 8.5. Copyright 2005 COMARCH SA

Transkrypt

1 Biuletyn techniczny CDN OPT!MA 8.5. Wzrost wydajności modułu kadrowo-płacowego Copyright 2005 COMARCH SA

2 Spis treści 1. WSTĘP METODYKA TESTÓW TESTOWANE PROCEDURY BADANIE WYDAJNOŚCI WERSJI 5.0: PORÓWNANIE WYDAJNOŚCI WERSJI 4.0 I 5.0: BAZY DANYCH BAZA DANYCH DLA 1000 PRACOWNIKÓW: BAZA DANYCH DLA 150 PRACOWNIKÓW: OPRACOWANIE WYNIKÓW ORAZ WNIOSKI SERYJNE NALICZANIE WYPŁAT TESTY NA WERSJI 5.0 DLA TYSIĄCA PRACOWNIKÓW PORÓWNANIE WERSJI 4.0 I 5.0 (150 PRACOWNIKÓW) SERYJNE NALICZANIE DEKLARACJI ROZLICZENIOWYCH ZUS (DRA) TESTY NA WERSJI 5.0 DLA TYSIĄCA PRACOWNIKÓW PORÓWNANIE WERSJI 4.0 I 5.0 (150 PRACOWNIKÓW, 500 PRACOWNIKÓW) SERYJNE NALICZANIE DEKLARACJI PIT TESTY NA WERSJI 5.0 DLA TYSIĄCA PRACOWNIKÓW PORÓWNANIE WERSJI 4.0 I 5.0 (150 PRACOWNIKÓW)....8 Testy wydajnościowe modułu kadrowo-płacowego Str. 2

3 1. Wstęp System CDN OPT!MA, zgodnie z wizją produktu, przeznaczony jest dla małych i średnich przedsiębiorstw, zatrudniających do 100 pracowników. W zakresie takiej ilości danych, wydajność modułu kadrowo-płacowego jest zadowalająca praca z programem nie jest uciąŝliwa, dotyczy to równieŝ operacji wsadowych, takich jak: seryjne naliczanie wypłat, deklaracji ZUS oraz PIT. Wraz z rozwojem funkcjonalnym projektu oraz z planami integracji z systemem CDN XL (w ramach tzw. duŝej płacówki ) pojawiła się kwestia wydajności seryjnych operacji w module kadrowo-płacowym dla baz o nawet kilkudziesięciokrotnie większej ilości pracowników oraz złoŝonych algorytmach wypłat. Dlatego waŝne stało się określenie miejsc w kodzie (i samej logice programu), które moŝna próbować zoptymalizować. JuŜ w wersji 5.0 zastosowano optymalizację niektórych istotnych procedur w płacach, zwłaszcza w deklaracjach. Celem niniejszych testów było zdiagnozowanie wydajności modułu oraz sprawdzenie wpływu zastosowanej juŝ optymalizacji na prędkość operacji i wykorzystanie zasobów systemowych. 2. Metodyka testów 2.1. Testowane procedury Badanie wydajności wersji 5.0: 1. Seryjne naliczenie wypłat dla 1000 pracowników za kolejne miesiące przez cały rok. 2. Naliczanie deklaracji DRA dla kaŝdego miesiąca (1000 pracowników). 3. Seryjne naliczanie deklaracji PIT-11 oraz PIT-40, równieŝ za cały rok (dla 1000 pracowników) Porównanie wydajności wersji 4.0 i 5.0: Seryjne naliczanie wypłat, deklaracji DRA oraz PIT-11 dla 150 pracowników, przy maksymalnie obciąŝonych wypłatach. Testy prowadzono na komputerach z zegarem 800MHz, 256MB pamięci RAM z systemem WindowsXP. Komputer dodatkowo był obciąŝony lokalnym serwerem bazy danych Bazy danych Baza danych dla 1000 pracowników: pracowników zatrudnionych na etat (ubezpieczonych, w tym kilku uczniów) - zróŝnicowana stawka zaszeregowania (od kilkuset do kilkunastu tys. zł w paru przypadkach), kilkanaście przypadków dopełniania do minimalnej - 99% pracowników ma po trzy dodatki (premię uznaniową, procentową i dodatek funkcyjny) - 28% ma potrącenie (liczone wg algorytmu 1) - losowo (ok.1/4, 1/5 ogółu) ma zasiłek rodzinny - ponad 7% ma zaniechanie podatkowe (rozliczane przez cały rok) - kaŝdy pracownik przynajmniej raz w roku był na urlopie wypoczynkowym (jeśli był tylko raz, to był to urlop dłuŝszy) - ilość dni urlopu losowa (nie przekraczająca miesiąca), część ma kilka dni, w co drugim miesiącu - ok. 22% pracowników było na zwolnieniu (lub zwolnieniach) lekarskim - niektóre zwolnienia przekraczały granicę 35 dni (zasiłek) - nieobecności obejmowały równieŝ przełom miesiąca - 5% pracowników było cały rok na urlopie macierzyńskim lub wychowawczym - część pracowników posiada urlop opiekuńczy, okolicznościowy, bezpłatny i nieobecność nieusprawiedliwioną - w kaŝdym miesiącu występują nadgodziny i spłaty zaliczek Testy wydajnościowe modułu kadrowo-płacowego Str. 3

4 Baza danych dla 150 pracowników: Rozkład elementów wypłaty oraz nieobecności proporcjonalny jak w bazie dla 1000 pracowników, jednak zdecydowanie częstsze wystąpienia dodatków (wszystkich algorytmów), nieobecności (większości typów) oraz nadgodzin. 3. Opracowanie wyników oraz wnioski Seryjne naliczanie wypłat Testy na wersji 5.0 dla tysiąca pracowników. naliczanie wypłat - średnia dla całego roku 7:00 6:00 5:20 6:10 5:00 4:38 4:04 czas [godz] 4:00 3:00 2:42 3:06 3:35 2:19 2:00 1:00 0:00 1:58 1:38 1:22 1:09 0:56 0:45 0:34 0:25 0:18 0:02 0:06 0: ilość pracowników Ryc.1. Średnia czasu liczenia wypłaty za rok dla bazy z 1000 pracowników. Testy wydajnościowe modułu kadrowo-płacowego Str. 4

5 Czas naliczenia wypłaty wzrasta dość jednostajnie do ok pracowników, przy czym następuje wyraźniejszy wzrost spowodowany rozpoczęciem tworzenia przez program swap-file a. Bezwzględne wyniki jednak wydają się zadowalające biorąc pod uwagę dość mocno obciąŝoną bazę. NaleŜy tutaj równieŝ zaznaczyć, Ŝe rzeczywiste listy płac (występujące u klientów) nie przekraczają z reguły pracowników (wynika to najczęściej ze struktury organizacyjnej firmy) i dla takich ilości pracowników wypłaty liczone są od kilku do kilkunastu minut. naliczanie wypłat za miesiąc 7:00 6:00 czas [godz] 5:00 4:00 3:00 2:00 styczeń luty marzec kwiecień maj czerwiec lipiec sierpień wrzesień październik listopad grudzień 1:00 0: ilość pracowników Ryc.2. Naliczanie wypłat dla kolejnych miesięcy. Algorytmy wypłat charakteryzują się przetwarzaniem danych naliczonych w poprzednich okresach/miesiącach. Dotyczy to sprawdzania przekroczenia podstawy emerytalno-rentowej, zaliczek, zaniechań podatkowych, chorobowego etc. Dlatego istniało ryzyko, Ŝe czas naliczania wypłaty z kaŝdym miesiącem będzie wzrastał, osiągając pod koniec roku wynik mocno odbiegający na niekorzyść od stycznia czy lutego. Testy nie wykazały jednak spadku wydajności wraz z kolejnymi miesiącami. Testy wypłat wykazały, Ŝe istotny wpływ na wydajność ma sam proces zapisu obiektów biznesowych. Wstępne prace w tym zakresie zostały juŝ podjęte dla wersji 6.0 i dotyczyć one będą zwiększenia wydajności całego programu Porównanie wersji 4.0 i 5.0 (150 pracowników). Podczas testów nie zauwaŝono istotnych róŝnic w czasie naliczania wypłaty pomiędzy obiema wersjami programu. Dla 150 pracowników (z bardzo mocno obciąŝonymi wypłatami) czas ten wynosił średnio 15 minut zarówno dla bazy lokalnej jak i sieciowej. Testy wydajnościowe modułu kadrowo-płacowego Str. 5

6 3.2. Seryjne naliczanie deklaracji rozliczeniowych ZUS (DRA) Testy na wersji 5.0 dla tysiąca pracowników. miesiąc czas (seria 1) czas (seria 2) styczeń 00:21:11 00:23:14 luty 00:24:26 00:20:28 marzec 00:19:27 00:23:22 kwiecień 00:21:32 00:23:45 maj 00:25:04 00:21:42 czerwiec 00:26:18 00:18:19 lipiec 00:20:03 00:21:01 Sierpień 00:21:44 00:20:21 Wrzesień 00:25:43 00:24:43 Październik 00:26:52 00:20:34 Listopad 00:19:22 00:22:10 Grudzień 00:23:43 00:23:10 cały rok (suma) 4:35:25 4:22: Porównanie wersji 4.0 i 5.0 (150 pracowników, 500 pracowników). W wersji 5.0 nastąpił istotny przełom w wydajności naliczania deklaracji DRA. Dotyczy to zarówno prędkości jak i wykorzystywania zasobów systemowych. W wersji 4.0 czas liczenia DRA wynosił średnio 80 minut, podczas gdy w wersji 5.0 spadł do 7-8 minut. Dodatkowo, program w wersji 5.0 nie jest zmuszony do tworzenia swap-file a, nie zaobserwowano gubienia pamięci. Dla 500 pracowników wzrost prędkości sięga wartości 40x. Dla tysiąca pracowników trudno o porównania, gdyŝ liczenie deklaracji starym sposobem nie kończyło się sukcesem w przypadku wersji 4.0 (przy załoŝonej konfiguracji komputera). Testy wydajnościowe modułu kadrowo-płacowego Str. 6

7 Wzrost wydajności liczenia deklaracji DRA pracowników 500 pracowników Czas [min] - wersja 4.0 Czas [min] - wersja 5.0 Ryc.2. Naliczanie wypłat dla kolejnych miesięcy. Tak wyraźny postęp spowodowany jest przyjęciem nowej koncepcji przetwarzania obiektów pracownika w obiekcie sesji (nadrzędnym dla większości obiektów biznesowych w OPT!MIE, zarządzającym tworzeniem, niszczeniem oraz zapisem innych obiektów). W wersji 4.0 wszystkie obiekty pracowników (tworzone w pętli) istniały w jednym obiekcie sesji. PoniewaŜ to sesja była odpowiedzialna za usuwanie z pamięci obiektów pracownika, więc dopóki nie zniszczono samej sesji, obiekty pracownika (obecne w kontekście tej sesji) nie były usuwane z pamięci. Zmiana w wersji 5.0 polegała m.in. na wielokrotnym tworzeniu obiektu sesji, dla tego obiektu tworzenie pracownika oraz niszczenie zarówno pracownika jak i samej sesji. Dzięki temu usunięto ryzyko pozostawienia w pamięci nieuŝywanych juŝ obiektów pracownika (jak równieŝ innych obiektów). Podobny mechanizm zostanie zastosowany równieŝ dla deklaracji zgłoszeniowych w wersji 6.0, choć w tym przypadku nie istniało ryzyko zbyt duŝego obciąŝenia pamięci operacyjnej. Testy wydajnościowe modułu kadrowo-płacowego Str. 7

8 3.3. Seryjne naliczanie deklaracji PIT Testy na wersji 5.0 dla tysiąca pracowników. ilość pracowników czas naliczania (deklaracja PIT-11) czas naliczania (deklaracja PIT- 40) 50 00:03:48 00:08: :04:22 00:08: :04:13 00:08: :04:07 00:08: :04:08 00:08: :04:12 00:08: :03:51 00:08: :04:05 00:08: :03:45 00:08: :04:22 00:08: :03:56 00:09: :04:03 00:08: :03:56 00:09: :03:56 00:09: :03:44 00:08: :03:44 00:08: :04:05 00:08: :04:01 00:08: :04:05 00:08: :03:54 00:08:56 NajwaŜniejszą informacją, która wynika z testów jest fakt znikomego lub wręcz Ŝadnego wpływu ilości pracowników na czas naliczania deklaracji. W przypadku PIT-40 czas jest średnio dwa razy dłuŝszy od PIT-11 spowodowane jest to większą złoŝonością samej deklaracji, gdzie oprócz danych bezpośrednio pobieranych z serwera (jak w deklaracji PIT-11) dokonywane są jeszcze pewne obliczenia w samej deklaracji (ściśle w obiekcie deklaracji) Porównanie wersji 4.0 i 5.0 (150 pracowników). W obu wersjach czas naliczania deklaracji PIT jest zbliŝony. Testy wydajnościowe modułu kadrowo-płacowego Str. 8