Wydajność dodatków przy pracy wielostanowiskowej

Zestaw manometrów pokazujących odczyty

Dodatek działający bez zarzutu na komputerze programisty potrafi zatrzymać pracę firmy, gdy uruchomi go dwadzieścia osób jednocześnie.

Blokady kartotek

Operacja obejmująca wiele pozycji blokuje je dla innych użytkowników. Handlowiec próbujący wystawić dokument czeka. Rozwiązaniem jest podział operacji na mniejsze części i zwalnianie blokad między nimi.

Zasada jest prosta: im krócej trwa pojedyncza operacja na danych, tym mniej osób na nią czeka. Dlatego operacje masowe dzieli się na paczki, zamiast wykonywać je jednym przebiegiem obejmującym całą kartotekę.

Długie operacje

Wszystko, co trwa dłużej niż kilkanaście sekund, powinno działać poza godzinami pracy albo w tle, z informacją o postępie. Zamrożony ekran skłania użytkownika do ponownego uruchomienia — i wtedy operacja wykonuje się dwa razy.

Potrzebne jest też zabezpieczenie przed drugim uruchomieniem przez inną osobę. Dwa równoległe przebiegi tego samego procesu potrafią stworzyć zdublowane dokumenty, a takiej pomyłki nie widać od razu — wychodzi przy uzgadnianiu.

Obciążenie bazy

Zapytania pobierające całą historię, żeby pokazać jedną liczbę, są najczęstszą przyczyną spowolnień. Zestawienie odświeżane cyklicznie bywa lepsze niż liczone przy każdym otwarciu ekranu.

Druga częsta przyczyna to pobieranie danych w pętli: dodatek odpytuje bazę osobno dla każdej pozycji dokumentu. Przy kilku pozycjach nikt tego nie zauważy, przy kilkuset — tak. Ten błąd widać dopiero na danych rzeczywistych.

Pomiar na danych rzeczywistych

Baza testowa z tysiącem dokumentów nie ujawni problemu, który pojawia się przy dwustu tysiącach. Test wydajności ma sens wyłącznie na kopii danych produkcyjnych.

Sam pomiar powinien odwzorowywać sytuację, która występuje naprawdę: kilkanaście osób pracujących jednocześnie, dodatek uruchomiony w godzinach szczytu, pełna baza. Zestaw takich prób opisujemy przy testowaniu dodatków przed wdrożeniem.

Wąskie gardło bywa gdzie indziej

Zanim zacznie się przyspieszać dodatek, warto sprawdzić serwer bazy: pamięć, dyski, indeksy. Bywa, że problem leży poza kodem.

Listę warto przejść po kolei: obciążenie serwera bazy, wydajność dysków, indeksy na tabelach, przepustowość sieci do stanowisk oraz to, czy kopie zapasowe nie wykonują się w godzinach pracy. Każda z tych rzeczy potrafi udawać problem z dodatkiem.

Co widzi użytkownik

Odczucie szybkości zależy nie tylko od czasu operacji, ale też od tego, czy program reaguje. Własny ekran, który pokazuje pierwsze dane od razu i doczytuje resztę, wydaje się szybszy niż taki, który czeka z wyświetleniem czegokolwiek do końca obliczeń — przy identycznym czasie łącznym.

Kiedy przyspieszanie się nie opłaca

Gdy operacja wykonywana jest raz dziennie poza godzinami pracy, a jej czas nikomu nie przeszkadza. Przepisanie działającego dodatku dla samej szybkości kosztuje i wprowadza ryzyko nowych błędów. Optymalizuje się to, co realnie zatrzymuje pracę ludzi.