Erre még mindig áll a fenti dolog. Már megint nincs kedvem dolgozni, ezért mesélek két példát.
Hasonló elvekkel írtak meg egy programot és futtattak egy programrendszert. Az eltérés csak annyi, hogy 1000 helyett 3M adat és napi működés volt az előírás. A program egy formátumkonverter előtét volt. A teljes programrendszer tartalmazott néhány sort jellegű műveletet is, ami több szegmensre darabolt adatokkal (a sort így működik) szintén lineárisnak tekinthető. Az eredeti futásidő 4 óra körül alakult.
Telt-múlt az idő, és az adatok néhány százalékkal bonyolultabbak és lassanként több mint kétszer annyian lettek...A futásidő meg "lineárisan" tartott a napi 120-130 óra felé. ;)
Átraktam egy 4-8x gyorsabb gépre a cuccost. A főnököm megbízta a tojáshéjas új kislányt a 19 órás konverter program újrakomponálásával és csiszolgatásával. Specifikáltam a feladatot és az eszközöket, valamint az új gépen futtatott cat jellegű programmal végzett sebességmérés alapján a 19 óra helyett - az adatok harmadára =2M - 14 perces futásidőt. Azért is, mert a megnövekedett adatmennyiséget bizonyos korlátok miatt már 3 részre kellett osztani. Ez a felosztás az addig lineáris működésű sorttmp területet négyzetesen lassítja, tehát kicsit hangolni kellett a diszkeket. Az előállított adatok vidéki telephelyekre terjesztését is módosítottam 3-4 óráról 8 percre. A végeredmény stabil 2 órás futásidő lett, ami a 130-hoz képest nem is olyan rossz. :)
Az adatmennyiség további növekedése és az idő vasfoga miatt meglépett újabb gépcserénél a számított futásidő 17 perc, a mért 12 perc lett. Igaz, ekkor már 5 szegmesre kelett osztani a 6->14M adatot.
Szerintem nem túl gyakori az olyan megoldás, amikor az adatmennyiség nő, a gép is gyorsul és a futásidő csökken. ;)
A másik példa pedig nem az offline feldolgozás területe. Az alap egy sybase karbantartó rendszer, 30-50 felhasználó és napi adatexport. Az egészet több öreg profi tervezte. Az adatbázis mérete 1GB + 3GB "játszótér", amelyhez 256MB memória is kell. Az export ideje 2 óra. Hozzáértő szakember (matematikus, aki 10 évig vitte a rendszert) el is magyarázta, hogy ez egy cat szerű művelet, nem igazán lehet gyorsítani.
Nosza, modernizáljuk a rendszert a szabványos eszközökkel, és irdatlan mennyiségű erőforrással!
(Hülyevagynemérteszhozzá! Az óra-kell, meg a táblaterek... :))
A végeredmény elég jó lett:
- A hardver 22x gyorsabb.
- A diszk és ram mennyisége leírhatatlan. ;)
- Alkalmazásszerver, korszerű felépítés, vékony kliens, nagy biztonság, stb.
- A munkavágzés sebessége az eredeti töredékére lassult. A felhasználók több perces várakozások mellett dolgozhatnak.
- Az export idő 2->19 óra. Magyarázom: belelóg a munkaidőbe, ami alatt a felhasználók malmoznak. Bár ez egy agy nélkül betervezett tűzfal elhagyásával 11 órára csökkent. Igaz, néha megvadult és akkor a futásidő értéke beláthatatlan lett. :-D
- A költségek 300->1500MFt és a rendszer még nem készült el.
Hosszabb ideig dolgoztam külsősként a cégnek. Véletlenül mindig akkor tárgyaltam a főnökkel, amikor megjelent egy emberke: Írd már alá a memóriabővítést! :-D
A fenti projekt rengeteg üde színfolttal rendelkezett. A projektet országos hírű szakember vezette, az egyetemen adatbázist tanított! A pörformanszra* vonatkozó aggályaimat rendre, gúnyos magyarázatokkal le is szerelte. (Én meg az elmúlt 10 évben az adatbázisszervert üzemeltettem, hangoltam.) A későbbiekben kiderült, hogy a jelenlévő 30 főből a tender címét csak hárman ismerjük. XD
* Columbo felügyelőnek magyarázzák: Tudja, olyan pörformansz! Amikor a színpadon belehugyozik egy pohárba és utána megissza.
Mi ebből a tanulság? Az üzleti siker nem mindig párosul a kielégítő működéssel. A fiatalok nem buták, - hiszen egy ilyen kijelentés az emberi jogaikat sértené :) - csak nem tanulták meg az alapos munkavégzést. Ebben pedig semmi hiba, hiszen nincs is rá szükség.