Użytkownik wyrasta z Novella

W warszawskich wodociągach, wprowadzając nowy unixowy ALPHA serwer, udało się przyspieszyć pracę systemu komputerowego ponad 12-krotnie.

W warszawskich wodociągach, wprowadzając nowy unixowy ALPHA serwer, udało się przyspieszyć pracę systemu komputerowego ponad 12-krotnie.

Wiele firm w Polsce ma podobnego typu problemy. Używają systemów komputerowych, które, początkowo dla niewielkiej liczby użytkowników i nie za dużej bazy danych, spisują się bardzo dobrze. Jednak z czasem ich wydolność coraz bardziej spada. Baza danych się rozrasta. Jej przetwarzanie zaczyna być bardziej złożone. W firmie komputeryzują się kolejne działy i wzrasta liczba użytkowników systemu. Zazwyczaj w programie pojawiają się stale nowe moduły. Wykonanie niektórych funkcji systemu staje się coraz bardziej czasochłonne. W pewnym momencie średnie czasy odpowiedzi systemu wzrastają tak znacznie, że dalsza jego rozbudowa, zarówno pod względem liczby użytkowników, jak i wielkości, staje się zdecydowanie niewskazana. Oczywiście można podejmować w takim momencie różne działania doraźne, mające na celu poprawę wydajności. A więc próbować optymalizować program pod względem szybkości działania, przerabiając jego kod. Jednak tego typu przeróbki mogą poprawić sytuację tylko do pewnego stopnia. Podobnie jest ze strojeniem systemu. I tutaj czasem można uzyskać pewną poprawę przez zmianę konfiguracji, tj. lepsze dopasowanie zmiennych systemowych. Jednak po wyczerpaniu tych prostszych metod zostaje nam jedynie wymiana sprzętu.

Właśnie dzięki zmianie serwera, przy równoczesnej zmianie platformy systemowej, w Warszawskim Przedsiębiorstwie Wodociągów Kanalizacji osiągnięto efekt dość spektakularny. W przedsiębiorstwie tym już od kilku lat funkcjonuje system komputerowy "zbyt wody" opracowany przez firmę Kom-pakt. W dużym uproszczeniu można powiedzić, że baza tego systemu zawiera kompletne dane dotyczące wszystkich wodomierzy na terenie Stolicy oraz dane dotyczące płatników za wodę na obszarze Warszawy i ich płatności. Przez te lata system funkcjonował pod kontrolą sieci Novell z serwerem Compaq ProSignia, wyposażonym w procesor 486. Nie jest to optymalne rozwiązanie dla dużej liczby użytkowników, a z czasem system "zbyt wody" w wodociągach "dorobił" się 40 stacji roboczych. Znacznie też wzrósł rozmiar bazy danych. Osiągnęła ona wielkość ok. 600 MB. Oba te czynniki spowodowały, że w szczytowych godzinach pracy wydłużył się znacznie średni czas odpowiedzi systemu, a także czas wykonania niektórych bardziej pracochłonnych funkcji. Firma Kom-pakt - autor funkcjonującej aplikacji podjęła się zadania przyspieszenia pracy systemu.

Czas na upgrade

Początkowo próbowano poprawić sytuację przez wprowadzenie znacznie szybszych komputerów, pracujących w charakterze stacji roboczych. Nie przyspieszyło to działania programu w wystarczającym stopniu. Postanowiono zatem zmienić serwer, ale było jasne, że kolejny novellowy serwer nie polepszy bardzo sytuacji, toteż zdecydowano się na unixowy DEC Server 2100. Jest to serwer wyposażony w procesor Alpha firmy Digital, wykonany w technologii wielopotokowej RISC, pracujący z częstotliwością 190 MHz, całkowicie 64-bitowy. Serwer ten może mieć do czterech procesorów i pracować pod kontrolą systemu Digital Unix. Tak więc wprowadzenie nowego serwera oznaczało także wprowadzenie nowej platformy systemowej. Aplikację napisano w Progressie; jest to język programowania 4 generacji, łatwo przenaszalny między różnymi platformami systemowymi. Dopasowanie DOS-owej wersji systemu "zbyt wody" do Unixu nie było skomplikowane, mimo że system ma ok. tysiąca zbiorów źródłowych i nie był początkowo pisany z myślą, że będzie funkcjonował pod innym systemem operacyjnym niż DOS. Progress jest pod tym względem niezawodny; aplikacja napisana w innym języku programowania mogłaby spowodować spore kłopoty przy przenoszeniu na inny system i wymagać dużego dodatkowego nakładu pracy. Wymogiem, który należało spełnić w trakcie przenoszenia aplikacji z jednego systemu na drugi, było nieprzerywanie bieżącej pracy w firmie. Z powodu obawy, że sobota i niedziela nie wystarczą na przeprowadzenie całej operacji, podzielono ją na dwa etapy.

Przenosiny

Po dołączeniu unixowego serwera najpierw przeniesiono na niego tylko bazę danych. Całą aplikację pozostawiono jeszcze pod kontrolą Novella. Tak więc był to wciąż model klient/serwer, który wymagał transmisji wielu rekordów do stacji roboczych. Okazało się, że takie rozwiązanie już przyspieszyło działanie systemu o ok. 1,5 do 2 razy. Nie było to jeszcze wystarczające przyspieszenie, ale też nie zamierzano na tym poprzestać. Następnie przeniesiono całą aplikację pod Unix. W sieci do przesyłania pozostały jedynie ekrany aplikacji. Okazało się, że to właśnie było to o co chodziło. Zabieg ten przyspieszył działanie systemu o ok. 12-20 razy w stosunku do sytuacji początkowej. Osiągnięte przyspieszenie było różne, w zależności od obciążenia systemu. Przy dużym jego obciążeniu wzrastało do 20 razy, a więc w tym najistotniejszym dla pracy firmy momencie efekt był jeszcze znacznie większy, niż podany w tytule tego artykułu. Tak więc okazało się, że tak naprawdę wąskim gardłem była pod Novellem transmisja rekordów z serwera do stacji roboczych.

Warto może dodać, że mierząc czas zrzutu na zbiór dyskowy bazy na obu serwerach stwierdzono 20-krotną różnicę. Były to odpowiednio czasy: dla Alphy - 1,1 godziny a dla Prosignia 486 - 21 godzin.

Koszty

Należy podkreślić, że dokonana operacja tak naprawdę nie wymagała żadnej wymiany sprzętu czy sieci. Było to jedynie poszerzenie dotychczas istniejącej konfiguracji sprzętowej. Wszystkie novellowe stacje robocze po prostu przestawiono w tryb pracy emulujący unixowe końcówki. Pewien kłopot stanowiło takie skonfigurowanie klawiatur dla nich, aby działanie poszczególnych klawiszy było identyczne jak poprzednio. Także i ten kłopot udało się pokonać. Zostały też w systemie pewne niewielkie aplikacje pracujące na dotychczasowym serwerze pod Novellem. Współpracują one bez przeszkód ze wspólną bazą danych. Są związane z obsługą przenośnych komputerów firmy Telxon, służących do wprowadzania odczytów wodomierzy w terenie i następnie ich zautomatyzowanego wgrywania do komputera.

Po przeprowadzeniu całej operacji warszawskie wodociągi długo nie powinny mieć kłopotów z szybkością działania systemu. Obecnie system jest "skalowalny", a więc stopniowa jego rozbudowa, dodawanie w programie nowych modułów nie powinno stwarzać większych problemów, a co najwyżej może pociągnąć za sobą konieczność dokupienia w przyszłości dodatkowego procesora.

Na zakończenie należy dodać, że taka zmiana niesie ze sobą dyskomfort "braku odwrotu". W warszawskich wodociągach nie wyobrażają sobie już powrotu do poprzednich rozwiązań systemowych i sprzętowych.