GoldenLine
Zaloguj się
Damian Kamiński

Damian Kamiński Zamieniam informacje
w wiedzę ...

Typowe pytanie gnębiące zapewne menagerów każdej firmy rozwijającej jakieś bardziej złożone oprogramowanie.

System (załóżmy ERP) dawno wyrósł poza założone na etapie projektu ramy (ponieważ żyje już od kilku lat), zaczynają się problemy typu, działa za wolno, raportowanie to udręka itd. generalnie wydajnościowa klapa. Firmą rozwijająca takie oprogramowanie staje przed dylematem, zacząć pracę nad nowym systemem od zera (na bazie doświadczeń), z ramami w których pomieści się naprawdę wielka firma, czy też łatać i upgrade’ować istniejący system.

Problemów w pytaniu ukrytych jest bardzo wiele, i żadne rozwiązanie moim zdaniem nie jest idealne, niemniej jednak każdy system który ewoluował z „mądrej” np. FKi, do systemu prawie ERP, wcześniej czy później napotyka takie problemy. Jak z niego wybrnąć najbardziej efektywnie ?Damian Kamiński edytował(a) ten post dnia 29.04.07 o godzinie 18:19
Link do wypowiedziLink
Maciej Kuś

Maciej Kuś właściciel, ibex.pl

Witaj,
To problem z serii: "czy stale naprawiać stare auto, czy wziąć kredyt i kupić nowe".
Miałem, mam i będę miał takie dylematy jak Ty.
W moim przypadku było tak, że system tworzony był przez lata, w atmosferze często zmieniających się wymagań - i prawie od początku postanowiłem budować go modułowo. Trochę za bardzo nawet, ale wolałem być ostrożnym :)

Podejście modułowe pozwoliło mi tworzyć system krok po kroku, łatwo rozszerzalny. Pozwala mi także "modernizować" system krok po kroku.
Ale rzecz jasna i tak tylko do pewnych granic.

Obecnie nie przeszłaby decyzja o tym, że budujemy system całkowicie od nowa... mimo, że zaprojektowany byłby lepiej, bo w oparciu o zdobyte doświadczenie. Więc póki co "modernizujemy" :)

Z drugiej strony tworzenie nowego systemu jest praktycznie koniecznością ze względu na rosnące wymagania użytkowników i szeroko rozumianą przyszłość produktu.

Ten problem został już przez ludzkość nazwany: "Syzyfowa praca" :)

Więc już konstruktywnie, moje zdanie jest takie:
- pisać od nowa, mimo że boli(kosztuje)(może tak mówię, bo lubię pisać :)
- jak najmniej zakładać z góry
- maksymalnie wykorzystywać stary kod
- dużo się modlić :)

Pewnie nie pomogłem, ale pozdrawiam :)
Maciek
Link do wypowiedziLink

konto usunięte

Witam,
mam bardzo podobne doświadczenia z przeszłości. Firma posiadała całkiem niezłe oprogramowanie, które latami ewoluowało z klasycznej FK, magazynówki czy Listy Płac. Całość urosła na tyle, żeby mówić o klasycznym ERPie, ale proces deweloperski zaczął kuleć. Implementacja nowych funkcjonalności wyglądała czasem trochę jak naciąganie przykrótkiej kołdry - nowa funkcjonalność w jednym module rozsypywała totalnie na pierwszy rzut oka nie powiązane funkcjonalności z innych modułów. Poza tym było to ciągłe łatanie wcześniejszych łat w kodzie, co oczywiście pociagało za sobą niefektywność całości kodu.
W pewnym momencie zarząd podjął odważną decyzję "piszemy od początku". Powstał nowy zespół "młodych-gniewnych" i "starych wyjadaczy", wykorzystano nowsze technologie bazując na wcześniej zdobytym doświadczeniu. Z perspektywy czasu widzę, że to była świetna decyzja - powstał elastyczny, nowocześniejszy system zintegrowany. Oczywiście nie zarzucono rozwoju "starej" aplikacji, ale stopniowo przerzucano siły na rozwój nowego systemu. Owszem, decyzja była bolesna, szczególnie na początku, ale na tym rynku i tak za wszystko zapłaci klient.

Reasumując, moim zdaniem - pisać od nowa, stopniowo "wygaszając" rozwój starych systemów. Niestety przed tym nie da się uciec biorąc pod uwagę zmiany technologii i klasyczny cykl życia produktu.
Link do wypowiedziLink
Marcin Stelmaszczyk

Marcin Stelmaszczyk em studio

Witam,
spotykam się z tego typu problemami dość często. Okazuje się bowiem, że programiści tworząc aplikację zapominają często właśnie o dwóch bardzo ważnych rzeczach. Mianowicie, że aplikacja nie kończy swojego życia w momencie wdrożenia. Tak na prawde, dopiero je zaczyna. Okazuje się jednak, że brakuje odpowieniej ilości narzędzi dodatkowych monitorujących jej działanie w realnym środowisku. Drugim elementem nie raz pomijanym są testy wydajnościowe. Przecież przy niewielkich ilościach danych, każda aplikacja będzie działać dobrze, a przynajmniej 'jakoś'. To 'jakoś', po kilku latach zamienia się właśnie na 'byle jak'.

Całkiem niedawno miała miejsce podobna sytuacja - system okazał się niewydajny. Kilka lat temu nie było takiego obciążenia ani tak ogromnej ilości danych. Podjęliśmy decyzję o stworzeniu nowego systemu. Zanim jednak rozpoczęliśmy prace, dokładnie przeanalizowany został stary system pod kątem wydajności. Okazało się, że istniały tam pewne 'wąskie gardła', przez co wydajność spadała drastycznie podczas normalnego użytkowania. Udało się nam zoptymalizować aplikację i pozbyliśmy się tych problemów. Jednakże prace nad nową wersją trwają, ale udało się nam 'ugrać' nieco czasu na budowę nowego systemu.

Doradzibym również analizę obecnego systemu zanim podejmie się decyzję o rozpoczęciu prac nad nową wersją. Generalnie najczęstszą przyczyną jest nadmiar danych i nie wydajne zapytania do baz danych.

Zauważyłem również pewną prawidłowość - co kilka lat należy zastanawiać się nad tym, czy nie warto sworzyć kolejnej wersj aplikacji. Świat pędzi do przodu i co trochę potrzeba nowej funkcjonalności, ciekawszych rozwiązań itp.

Pozdrawiam i życzę powodzenia
Marcin
Link do wypowiedziLink
Arek R.

Arek R. Chyba czas na zmianę
- SAP (BW, BPC,
FICO) Development
Te...

Damian K.:
...ciach... Jak z niego wybrnąć najbardziej efektywnie ?Damian Kamiński edytował(a) ten post dnia 29.04.07 o godzinie 18:19

Trzymac sie jak najdalej od firmy Comarch i jej produktow.....(nie)stety potwierdzone przez zycie....
Link do wypowiedziLink
Damian Kamiński

Damian Kamiński Zamieniam informacje
w wiedzę ...

Niestety bolączka o której mówię nie dotyczy tylko produktów Comarch’u, firmy polskie i zagraniczne można długo wymieniać, ale nie o to chodzi mi w tej dyskusji.
Link do wypowiedziLink
Piotr Wolański

Piotr Wolański Programista

Problem wydajności i w ogóle utrzymania systemów IT (nie tylko ERP) bardzo często powodowany jest tym co ja nazywam "syndromem konsultanta". Zewnętrzna firma wdrażająca oprogramowanie zainteresowana jak najszybszym i najtańszym (z jej punktu widzenia) wdrożeniem systemu u klienta - utrzymanie systemu to już problem klienta - jak będzie miał problemy - będzie znowu okazja, żeby konsultanci mogli zarobić. Ewentualnie namówimy klienta na zakup nowego systemu (albo na nowy serwer)
Jedno z praw Murphy'ego głosi "Prawdziwa mądrość polega na unikaniu perfekcji"
W przypadku oprogramowania "autorskiego", budowanego bezpośrednio w przedsiębiorstwie dużo zależy od osoby, która kieruje jego rozwojem. Ogólnie sprawdza się zasada, że oprogramowanie rozwija się dopóty, dopóki istnieje chociaż jedna osoba, która potrafi ogarnąć całość. Po przekroczeniu tego magicznego progu zaczynają się problemy. Jednym z objawów jest podzielenie oprogramowania na moduły lub "strefy wpływów" którymi zajmują się osobni programiści/grupy programistów i to jest już ostatni dzwonek.
Od tego momentu modyfikacja programu a zwłaszcza "rewolucyjne" zmiany są już praktycznie niemożliwe ze wzgledów psychologiczno-organizacyjnych.
"Dlaczego to my mamy mieć problemy - jeżeli mogą mieć oni - niech oni przerabiają"
"Dlaczego nasz dział ma teraz wprowadzać te dane - zawsze wprowadzali to inni"
"Ja chcę mieć w nowym systemie taki sam raport jak poprzednio" i nieważne, że nowym systemie nie da się go zrobić, nie jest już potrzebny lub dane zawarte w nim oznaczją już coś innego.
Optymalizacja jest wymuszana wtedy, gdy raporty zaczynają się liczyć w "czasie rzeczywistym" tzn. raport tygodniowej sprzedaży liczy się .... tydzień ;-)

Natomiast trochę innym problemem jest sytuacja, gdy mamy system jaki mamy, ale potrzebujemy wiekszej wydajności.
Standardowe rozwiązanie zaproponowane przez większość konsultantów: wymienić komputery na szybsze sprawdza się, ale nie zawsze, ale jeżeli system jest zakupiony "pod klucz" to i pole manewru jest małe.
W przypadku systemu "autorskiego" pole manewru jest dużo wieksze, ale warunkiem podstawowym jest istnienie osoby, która jest w stanie to ogranąć, a o to coraz trudniej...
Link do wypowiedziLink
Piotr Wolański

Piotr Wolański Programista

Zestawienie poniżej obrazuje co dzieje się z wydajnością systemu
w którym ze wzgledu na przyrost danych raport,
który po pierwszym miesiącu wykonywał się 100 sekund
w każdym następnym miesiącu wykonuje się o 2% wolniej niż w poprzednim.
Jak widzimy, przy takim założeniu co 3 lata
musimy kupić sprzęt 2 razy bardziej wydajny,
żeby przywrócić poprzednią wydajność.
Jeżeli spadek wydajności jest większy niż 2%
to następne kolumny pokazują co nas czeka.

miesiąc 2% 5% 10%
1 100 100 100
2 102 105 110
...
12 124 171 285 - 1 rok
...
24 158 307 895 - 2 rok
...
36 200 552 2810 - 3 rok
...
48 254 991 8820 - 4 rok
...
60 322 1779 27680 - 5 rok

A teraz propnuję odpowiedzieć na proste pytanie:
Jak powinien być zaprojektowany system (jaka złożoność algorytmów), żeby nie reagował spadkiem wydajności przy comiesięcznym przyroście danych.
Pytanie alternatywne:
Z jakim zapasem musimy kupić system na starcie,
żeby przeżył 5 lat ;-)Piotr Wolański edytował(a) ten post dnia 30.04.07 o godzinie 21:49
Link do wypowiedziLink
Karol Wojtiuk

Karol Wojtiuk Team Leader, SMT
Software

Niestety zawsze tworząc jakąś aplikację opierasz się na aktulanie obowiązujących paradygmatach (jak choćby słynne zawołenie Billa Gatesa, że 640 KB RAM wystarczy dla każdego - z lat osiemdziesiątych - dla młodszych wytłumaczenie: wtedy to naprawdę brzmiało racjonalnie, a nie idiotycznie) i w oparciu o bierzące znane ci wzorce programowania, wydajności komputerów, itp, itd starasz się zrobić oprogramowanie "good enough". Oczywiście można się pokusić o prognozowanie zmian technologii, obciążenia aplikacji, itd, ale racjonalnie rzecz biorąc, to nie da się zrobić prognozy dłuższej niż dwa lata (w porównaniu z prognozą pogody to i tak niezły wynik :) ).
Reasumując, nie ma łatwego przepisu na to czy lepiej łatać, czy pisać od nowa. Za to na pewno trzeba założyć, że w łatwo przewidywalnym okresie nasza aplikacja będzie do niczego. A w związku z tym, jeśli tylko się wypuści na rynek aplikację, to już powinny się zacząć prace nad jej nową wersją. Tu nie trzeba odkrywać ameryki, wystarczy popatrzeć co robią i jak robią "wielcy" tego rynku.
Link do wypowiedziLink

konto usunięte

wielcy też mają probelmy z wydajnością i to często duże. natomiast przyczyny sa często złożone, ale jest klika głównych:

1) brak optymalizacji/konserwacji systemu przez klienta w ramach bieżącej administracji (bo nie nasz system)
2) niedoszacowanie wymagań co do wydajności platformy sprzętowej w trakcie wdrożenia (bo musi być tanio)
3) naturalny proces spadku wydajności w wyniku przyrostu danych (ciężko wymagać, żeby dane rozwiązanie skalowane pod liczbę transkacji x+50% działało tak samo wydajnie przy x+500%
4) przestarzałe techniki programowania (baaardzo częste)
5) brak optymalizacji kodu i zbytnia komplikacja algorytmów (błędy programistyczne)

więc cóż. nie spodziawamy się chyba, że syrenka z 70 roku będzie dorównywała osiągom porsche z 2000 roku, prawda? przy systemach też to działa. nie ma możliwości stworzenia czegoś co będzie wiecznie działać tak samo dobrze przy cały czas rosnącej ilości danych. i tu się kłania cykl zycia produktu. produkt trzeba rozwijać i modernizować, a nawet czasem napisać od początku. a w tym pomaga wyobraźnia i patrzenie w przyszłość przy projektowaniu systemu. i tyle.
Link do wypowiedziLink
Rafał D.

Rafał D. Head of Production,
Locon Sp. z o.o.

Piotrze, mi oczywistym wydaje sie ze w najgorszym wypadku powinna byc zlozonosc liniowa. Jesli programy tak jak w Twoim przypadku maja zlozonosc wykladnicza (?) (zalozylem ze dane w czasie przybywaja liniowo) to chyba nic dziwnego ze rozwali nam to wydajnosc. Dla mnie takie podejscie jest niedopuszczalne.

Z tym ze kto projektujac system i opierajac sie o wszystkie gotowe rozwiazania (dajmy na to Java i jakas baza danych) analizuje zlozonosc?
Link do wypowiedziLink
Piotr Wolański

Piotr Wolański Programista

Rafał, miałem na myśli, że złożoność liniowa to _już_ jest poważny problem.
Jeżeli np. do tabeli z pozycjami faktur dopisuje się powiedzmy 1 mln rekordów miesięcznie i teraz raport wyszukuje te rekordy to wyszukiwanie z uzyciem indeksu ma złożoność o ile pamiętam ln(n) a to oznacza, że po roku tylko czas wyszukiwania jednego rekordu jest 2 razy dłuższy (a jest to optymistyczne założenie bo jeszcze trzeba doliczyć narzut na odfiltrowanie "niepotrzebnych" rekordów przy bardziej złożonych raportach)
Złożoność liniowa oznaczała by, że po roku raport liczy się 10-12 razy dłużej :-(
Link do wypowiedziLink
Piotr Wolański

Piotr Wolański Programista

Rafał D.:
Z tym ze kto projektujac system i opierajac sie o wszystkie gotowe rozwiazania (dajmy na to Java i jakas baza danych) analizuje zlozonosc?

Na pewno wszyscy ci, którzy mieli do czynienia z utrzymaniem/konserwacją dużych baz danych :-)
Wtedy najczęściej trzeba porzucić eleganckie rozwiązania obiektowe i przeprosić się z relacyjnymi bazami danych ;-)
Link do wypowiedziLink

konto usunięte

Witam serdecznie,

Panowie, przyjaciele po fachu ;)
Wszystko związane jest z cyklem życia aplikacji, każda z nich kiedyś kończy swój żywot - jedną z przyczyn często jest spadek wydajności.
"Przychodzą" nowe, lepsze technologie, dające więcej możliwości - normalny zatem jest, że proces tworzenia systemu zaczyna się od podstaw.
Pytanie jednak które chciałbym zadać to jak podchodzicie do przenoszenia danych z jednego systemu do drugiego w trakcie tworzenia tego drugiego? (wiem masło maślane :P).

Kwestia która mnie mocno interesuje to sytuacja kiedy nowy produkt jest skończony w 80% i importujemy do niego dane, jednocześnie nadal go aktualizując.
Jak np. panujecie nad schematami danych? Ich wersjonowaniem itp?

Dodam również, że najczęściej przyczyną problemów wydajnościowych jest brak testów wydajnościowych przy użyciu odpowiednich narzędzi to raz, a dwa przy zastosowaniu tego samego środowiska/architektury jak sprzęt docelowy. Ostatnio w takich sytuacjach ratuje nam "skórę" różnej maści narzędzie do wirtualizacji systemów operacyjnych. Pytanie - korzystacie z takich narzędzi? (typu VM Workstation) ?

pozdrawiam,
Patrycjusz Szydło
Link do wypowiedziLink
Piotr Wolański

Piotr Wolański Programista

Patrycjusz Maciej S.:
Pytanie jednak które chciałbym zadać to jak podchodzicie do przenoszenia danych z jednego systemu do drugiego w trakcie tworzenia tego drugiego?

Nie przenosimy, dzięki temu mozemy wykazać, że nowy system działa szybciej ;-)

A tak naprawdę, to dawno, dawno, temu... dane każdego miesiaca trzymane były oddzielnie, bo od razu widać było jak spada wydajność. Teraz mamy szybkie serwery baz danych i nie musimy partycjonować danych na bieżące i archiwalne, a wydajność ... dalej spada ;-)
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy



Wyślij zaproszenie do
Anuluj