Witam
od pewnego czasu mam problem z generowanie raportu - lista płac.
Zazwyczaj raport generował się w kilka, kilkanaście - max kilkadziesiąt sekund.
Obecnie mam kilka okresów pootwieranych -
raport za styczeń, luty marzec - generuje się szybko.
za kwiecień trwa już kilka minut!
za maj kilkanaście - kilkadziesiąt !

Czy ktoś gdzie jest problem, i jak można go rozwiązać ?

pozdrawiam
PiotrG

Pozamykaj okresy!

[quote="GipsonTHEone"]Witam

Obecnie mam kilka okresów pootwieranych -


Czy ktoś gdzie jest problem, i jak można go rozwiązać ?
/quote]


Jeżeli wchodzimy/liczymy maj KD musi uwzględnić okresy poprzednie - choćby żeby sprawdzić czy pracownik nie wchodzi w II próg.
Jeżeli są zamknięte: odczytuje dane z bazy (szybko) jeżeli otwarte: musi je ponownie naliczyć.

Oznacza to że wchodząc do maja Symfonia w Pana przypadku nalicza 5 okresów a nie jeden.
W grudniu będzie większy problem :).

Witam
zamykanie okresów oczywiście pomaga.
Nie mniej jednak np w przypadku fundacji która prowadzi po kilka projektów do każdego zakładam okresy.
Bywa i tak że w miesiącu mam pootwieranych 10 okresów. Problem jest irytujący.
Czy zakup pervasive sql rozwiązał by problem ?

Nie, bardziej przejście na ERP (już nawet bez Extra)
Czy projekty są rozliczane w okresach podstawowych czy pomocniczych?
Rozumiem że pracownik A naliczany jest tylko w okresie Y i Z a B tylko w okresie X i Z? ( przypominam że wykazane zera na zakładce płace oznacza że pracownik jest naliczony w okresie i to też trwa).

Pervasive tez znacznie pomoze :)

Proszę Cię, ja też pracuję w Fundacji i też mam od kilku do kilkunastu projektów ale nie zakładam do nich nowego okresu tylko grupuję je i podpinam pod jeden okres i wszystko zamykam na początku następnego miesiąca. Wymaga to trochę pracy na początku projektu ale potem zamykają się bezproblemowo.

Możesz jaśniej w jaki sposób grupujesz?
Obecnie tworzenie osobnych okresów pod projekt jest po to, żeby w prosty sposób generować listę płac dla danego projektu. Jeśli masz jakiś lepszy sposób - słucham, chętnie sprawdzę inne rozwiązanie.

pzdr

Postanowiłem wykonać szybki test:

Lokalnie na laptopie, lista płac za styczeń - marzec 2015, baza demo:
40 SEK, 01-03, LISTA PŁAC PODSTAWOWA pervasive
35 SEK, 01-03, LISTA PŁAC PODSTAWOWA btrieve
35 SEK, 01-03, LISTA PŁAC PODSTAWOWA pervasive (powtórzona)

przez sieć
0'45", 01-03, LISTA PŁAC PODSTAWOWA btrieve
0'46", 01-03, LISTA PŁAC PODSTAWOWA btrieve
0'20", 01-03, LISTA PŁAC PODSTAWOWA btrieve - drugi raz ta sama (pamięć podręczna btrieve 256MB)
4'20"(!), 01-03, LISTA PŁAC PODSTAWOWA pervasive
0'38", 01-03, LISTA PŁAC PODSTAWOWA pervasive - po ustawieniu parametru Use Cache engine w konfiguracji klienta pervasive
0'20", 01-03, LISTA PŁAC PODSTAWOWA pervasive - drugi raz ta sama


Powyższe testy nie były wykonywane w warunkach laboratoryjnych i dotyczą wyłącznie generowania LP ale myślę że wnioski można rozszerzyć na ogólną wydajność Kadr.
Wychodzi że przy używaniu Pervasive i w instalacji sieciowej mamy zysk ok. 20% na liście płac.
Jeżeliby kupować Pervasive w aktualnej promocji za 1 zł. to jak najbardziej, ale poza promocją o ile chodzi nam tylko o przyspieszenie, to Pervasive wydaje mi się tylko kolejnym etapem na drodze do ERP.

A ile ustawiles cache w serverze pervasive?

Popatrzyłem: domyślne jak się okazuje 32MB, zwiększyłem do 320MB na laptopie teraz wyszło 37sek (jak pisałem nie są to warunki laboratoryjne).
Cache btrieve ustawiłem na 256MB bo często mam zwyczaj zmiany domyślnej wartość 4MB - w zasadzie dla idei, bo wg mni kompletnie nie ma to wpływu na wydajność kadr.

Jutro będę mógł sprawdzić przez sieć ale też nie spodziewałbym się rewolucji w wynikach.

Pozdrowienia.

Cache ma wpływ - ale tylko wtedy gdy jego rozmiar jest nieco wiekszy niz laczny rozmiar katalogu bazy i całość bazy jest cacheowana

Pozwoliłem wykonać więc sobie jeszcze jeden test:

Program na laptopie, baza cały czas demo_kd, 255MB, baza przez udział "S":

Cache 1GB
bTrieve
38 sek pierwszy przebieg
18 sek drugi

pervasive
35 sek pierwszy przebieg
18 sek drugi

Postanowiłem pójść w drugą stronę i ustawić minimalny cache (już tylko bti)
Cache 1MB
38 sek pierwszy przebieg
17 sek drugi (???)



Niejako w międzyczasie doszło do mnie, że poprzednie testy "lokalnie" wykonywałem na laptopie (i5 2,13GHz) a wersję sieciową (przez udział) na komputerze stacjonarnym i5,3,8GHz.

Przerzuciłem więc bazę na stacjonarny i5 3,8GHz, SSD, cache btrieve 1MB jak z ostatniego testu:
tylko bti
20 sek

i to samo na na stareńkim magnetycznym dysku 320GB:
tylko bti
20 sek

To co rzuca się w oczy jest brak "wrażliwości" na szybkość dysku. Potwierdza to dawne moje testy kiedy Kadry wrzuciłem na RAMdysk. Wtedy wnioski były takie że "no, przynajmniej nie zwolniły". Efektem tego zapewne jest też niewielka zależność od pamieci podręcznej silnika bazodanowego. Choć podkreślić należy że wykonywałem wyłącznie test na drukowaniu listy płac, być może cache w normalnej pracy (ciągłe przełączanie między okienkami i pracownikami) może mieć jakiś wpływ.

Natomiast widzimy różnicę w zależności od mocy procesora, co w pewnym stopniu też potwierdza poprzednie doświadczenia czyli zdecydowany zysk przy przejściu z systemów pentiumopochonych na Core2Duo i pochodne, czy też tragiczną wydajność na Celeronach opartych o Pentium IV. U jednego z klientów Kadry na PIV 3,2GHz pracowały prawie 3-razy wolniej niż na Core2Duo 2,66Ghz biurko dalej.


Powstaje więc pytanie a na jakim sprzęcie pracują panie w Kadrach?



ps. Dodam, że u dwóch klientów, którzy przeszli na Forte Lista płac generowała się bez mała 3-krotnie szybciej niż na Premium i po przekazaniu baz do eksploatacji nie było żadnych wątpliwości czy jest szybciej. Jeżeli chodzi o Kadry i Forte to jestem za :). Niejako dodatkiem do Forte jest to, że jeżeli z jakiegoś powodu program nie może zamknąć pracownika to w drugim podejściu do zamykania okresu program ma do zamknięcia tylko tego jednego pracownika a nie z powrotem wszystkich. Oraz mamy możliwość otwierania okresu tylko dla jednego pracownika.

Też mnie zżera ciekawość.
Choć jestem zdania że przy założeniu że potrzebujemy pokazać:
- "500 PLN" za projekt A + od tego składki i PDOF
- "1500 PLN" za projekt B + od tego składki i PDOF

to da sie to zrobić wyłącznie na podokresach.

Albo kombinować w jednym okresie t.j stworzyć komplet składników i jakieś podzielniki do tego:
"Projekt A", "Projekt A - składki" "Projekt A PDOF" i takie tam dalej
"Projekt B", "Projekt B - składki" "Projekt B PDOF" i takie tam dalej
"Projekt C", "Projekt C - składki" "Projekt C PDOF" i takie tam dalej
i liczyć na to, że nie każą nam rozliczać więcej niż 3 projekty w okresie dla pracownika.

Witam
u mnie to Core i5 (2,9 Ghz) , 4gb ram, dysk SSD.
Pytanie czy robiłeś testy na jednym okresie czy wielu w kilku miesiącach.
interesuje mnie np przy otwartych 2, 3 miesiącach po kilka okresów w miesiącu.
jaka będzie różnica w generowaniu list płac między bazą standardową oraz opartą o PSQL.

Ciekawostką jest że podczas generowania listy procesor obciążony jest tylko ok 23%, a program się podwiesza.