2010/11/4 Alex 'CAVE' Cernat <[email protected]> > > > Nu, nu glumesc, majoritatea minunatiilor de mai sus le-am vazut in > > medii in care criteriile au fost "repede si ieftin" si imho you're way > > better off lasandu-i sa-si vada de pandaliile lor. Fast, cheap, > > reliable - pick at most two > Stai calm, am vazut si in medii 'academice' aplicatii facute cu curu, nu > mai vorbim de tabele unde doar primary key e indexat, ca ala oricum a > fost pus automat, plus tot felul de query-uri cretine cand se putea > rezolva mult mai simplu si mai eficient. Dar deh, gandirea unei > aplicatii la noi cam lipseste, hai sa-i dam drumul mai repede ca deh, e > deadline. Iar de testare ce sa mai vorbim: facem teste ca merge, teste > de performanta ioc, de fapt testele de performanta se fac online nu ? Si > atunci vedem daca tine sau nu. > Binenteles, adminu e de vina ca saracu server nu mai suporta kkt-ul ala > de aplicatie, in conditiile in care si eu il faceam de 2 ori mai bine > fara sa ma chinui prea tare intrand in optimizari de alea de neam prost. >
Pai din punctul meu de vedere, lucrurile sunt destul de simple, acum depinde de ce parte a baricadei te afli (vendor side/customer side). Daca tu esti furnizorul de servicii/hosting/colocation, etc, si clientul a cumparat un anumit serviciu de la tine, e problema lui cit din acea capacitate foloseste (ideal ar fi sa foloseasca 100%, intr-un mod optim, pentru ca de aia plateste nu ?). Acuma daca el are o aplicatie care e varza, nu e problema ta, chiar ar trebui sa te bucure (pentru ca o sa ii vinzi mai mult hardware, evident :) ). Tu ii oferi statistici de performanta si ii explici ca asta e maxim pentru ceea ce plateste si ii oferi solutii (upgrade de hw, capacity on demand, etc). Daca esti sysadminul/consultantul la fel, culegi statistici si ii explici unde e problema. Eu de ex. recent am avut o problema de perfiormanta cu o DB (de marime mica spre medie dupa parerea mea) care tinea disk-urile in 100% in timpul unui batch.Evident, toata lumea trimitea screenshot-uri si le explica managerilor ca disk-urile sunt 100% utilizate si acolo e problema. Eu le-am explicat ca asta este numai o consecinta, nu si cauza. Le-am aratat ca ORacle genereaza cam 2000 IOPS, ca numarul de disk-uri din SAN array nu poate servi mai multe, si ca daca nu vrea sa convinga developerii/DBA sa analizeze atent query-urile, eu ii pot aloca un array care o sa ii asigure 3000 IOPS ( evident, asta cu un anumit COST) dar ca nu o sa ii rezolve problema in conditiile in care peste o luna s-ar putea sa aiba nevoie de 4000 IOPS. Si managementul nu m-a mai deranjat deloc din clipa aceea.Evident, asta pina la urmatoarea problema de performanta :) > Alex > > _______________________________________________ > RLUG mailing list > [email protected] > http://lists.lug.ro/mailman/listinfo/rlug > _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
