Ha új hardvert vesz a cég (szerver, storage), a teljesítményét elsősorban...

Címkék

...egy vagy több elterjedt iparági módszerrel mérjük (Linpack, PovRay, SuperPI...)
5% (19 szavazat)
...saját eljárással mérjük (pl. egyedi feladat futtatása)
24% (95 szavazat)
...nem mérjük (nem érdekel vagy megbízunk a szállító/kereskedelmi benchmark adataiban stb.)
51% (201 szavazat)
Egyéb, leírom hozzászólásban (ha érdemes)
19% (76 szavazat)
Összes szavazat: 391

Hozzászólások

Miért kérdezem?

Sokszor látom, hogy egy jelentősebb méretű új infrastruktúra mérések nélkül, tapasztalati alapon vagy a beszállító javaslata szerint van méretezve, illetve azt is csak felületesen ellenőrzik, hogy pontosan mennyi a teljesítménynövekedés (összevetve az energiafogyasztással és egyéb kísérő tényezőkkel).

A kérdés vonatkozhat hálózatokra is, de én elsősorban számítási kapacitás és storage szempontjából tettem fel.

---

Ha valakinek megvan a konkrét benchmark módszertana is, örömmel venném, ha néhány sorban leírná, milyen workload-ot és milyen eszközökkel vizsgál!

Viszont ha még üzleti igények sincsenek kidolgozva (a mennyi erőforrás kell az alkalmazás kérdésre bambán néznek rád, mennyi user lesz kérdésre szintén mereven bámulnak az illetékesek maguk elé), akkor elég nehéz méretezni. Ebben az esetben csak a tapasztalatra és a technikai paraméterekre hagyatkozhat az ember. Ezekből utána nagyon nehéz jó rendszert építeni ráadásul úgy, hogy a határidők nagyon szorítanak.
Persze ideális eset lenne előtte benchmarkolgatni, de egy nagy infránál erre nagyon kevés az esély, mert melyik szállító dob le demózni ~1 évre komplett infárhoz vasat? Meg egy év alatt biztos fejlődik a technológia, kijönnek az újabb generációs eszközök.

--
http://laszlo.co.hu/

+1, az egyetlen igazi mérés maga az éles futtatás. Hiába fut a vason 900000+ FPS-el a nemtomGL teszt, ha neked IO performance kell, vagy fordítva. A teljesítmény mérés csak akkor releváns, ha már előre tudod pontosan, hogy milyen típusú teljesítményből mennyit vársz *és* azt is tudod előre, hogy a futó alkalmazás algoritmikusan hogyan skálázódik *és* azt is tudod, hogy a userek igényei hogyan fognak skálázódni. Máskülönben csak random számokat mérsz ami jó a CHIP magazinba grafikonnak, de nem fogja megmondani, hogy neked elég lesz-e.

--
The Net is indeed vast and infinite...
http://gablog.eu

Mert az esetek többségében az üzleti oldalnak halvány fogalma nincs arról, hogy mik az elvárásai az új IT infrastruktúrával szemben. Ha meg kérdezel (mennyi user, milyen és mennyi alkalmazás, adatbázis, stb., akkor néznek rád bambán, mintha egy másik galaxisból érkeztél volna...)Jobb esetben. Rosszabb esetben arról sincs fogalma a megrendelőnek, hogy a jelenlegi rendszere milyen, így aztán arra sem tudnak adatot adni, hogy azt a nyomorult rendszert mégis milyen terhelésre kellene méretezni a beszállítónak... így marad a kiépítendő rendszer teljesítményének a korábbi hasonló projektekben szerzett tapasztalatok alapján történő hasra ütéssel való "méretezése"...

Ha van rá lehetőség, akkor azzal a szoftverrel/szoftverekkel ami majd futni fog rajta/rajtuk, storageot/SAN-t dd-vel :)

("megbízunk a szállító/kereskedelmi benchmark adataiban" azért ezt te sem gondoltad komolyan?!)

egyeb: a vasarlasnal nemigen merunk, mondjuk ugy hogy hiszunk a beszallitonak, a sajat becsleseinkben, meg egyszeruen csak "nagyobbat" veszunk. De kesobb a sajat szofverunk teljesitmenyet merjuk (ebbol adodoan "sajat eljarassal") az adott hw-en (nem is elsosorban a hw teljesitmenye miatt, de nyilvan az is jelentos szerepet kap).

En elsosorban olyasmire gondoltam, ahol a teljesitmeny nagyobb feladathoz lett vasarolva (pl egy kozep/nagyvallalati mailszerver, valami Java alapu webes szolgaltatas-architektura, portal stb), es helyenkent meg lehet erezni a hardver teljesitmenyenek hatarait. Ebben az esetben nyilvan nem mindegy, hogy a kovetkezo generacioval mekkora novekedesre lehet meg szamolni. Illetve vannak az olyan esetek is, amikor pl a backup vagy valamifele adatbazisban futo nagy job tul lassu, es garancia kell arra, hogy pl egy hetvege alatt valoban vegez.

mert az, hogy a jávás cuccod mennyi teljesítményt fog elvinni, olyan jól lehet előre tudni:)
mert az nem fordul elő, hogy mellényúl a programozó egy-két dolognak, sql-nek, és ettől hirtelen sokszorosára nő a teljesítményigény:)

Most megmondom neked látatlanban, mennyi erőforrást zabál fel egy vállalati jávás rendszer: az összeset :)

Pedig félig igaza van neki.
A GC-kre nem igazán jellemző, hogy visszaad memóriát a rendszernek, a "könyv" szerint
kellene, de gyakorlatilag ritkán kerül rá sor.
Viszont ezért azért kap is valamit az ember.. a hardver meg egyre "olcsóbb".
Még mindig jobb egy java mint a ruby nevű köcsögség, aminél trágyább, erőforrás zabálóbb nyelv nincs.
Divat szar.

Az általam eddig látott összes magát enterprise-nak nevező cégek összes java sz*ra egy kb használhatatlan erőforrászabáló szemétnek bizonyult. Juniper NSM, Cisco ISC,CSM,ANM, a HP bármilyen! szoftvere (HPOV sorozat) stb...,

Lehet, hogy ezek hulladékok (azok) + a cégek is csak akkor mutasson már nekem valaki egy normális java szoftvert (kliens v szerver oldali is lehet)

Most hogy mondod használunk JIRA-t sebesség szempontjából egészen jó, bár, hogy ehhez mi kell a szerver oldalon azt nem tudom, mert erre pont nem látok rá.

Én nem kétlem, hogy lehet nagyot alkotni, arra próbáltam inkább reagálni, hogy a fentebb említett nagy cégeknél talán? nem hulladék programozók dolgoztak, az eredmény mégis siralmas. Lehet, hogy naív vagyok, nem tudom. Szóval nem azt mondom, hogy a java mint platform predesztinálja az erőforrászabálást/lassúságot, csak az én területemen használt szoftverek folyamatosan az ellenkezőjét bizonyítják.

amikor pl a backup vagy valamifele adatbazisban futo nagy job tul lassu, es garancia kell arra, hogy pl egy hetvege alatt valoban vegez.

erre a jo megoldas az, hogy az ismert, megbizhato beszallito teljes megoldast szallit. Ertve ezalatt, hogy az igeny az, hogy: ferjen be a heti mentes 4 oraba! Erre a beszallito azt fogja mondani, hogy a kimeresbe, tervezesbe fektetett mernokora 5 misi, vagy ha ohalytod ezt berakjak a hwkoltsegbe.

A kerdes inkabb, hogy hogyan teszel szert megbizhato beszallitora. mondjuk evolucios uton...

Szerintem: a legfontosabb szempont, hogy az eladó mennyit tejel a döntéshozónak.(Bocs)
---------------------------------------------------------------------------
Környezetvédelmi nyilatkozat: Ez a hozzászólás kizárólag reciklált elektronok felhasználásával íródott.

Szerinted van olyan beszerzés nagyobb cégeknél, ahol nincs ilyen? naiv vagy... Ahol nem a tulajdonos költi a saját pénzét, hanem más, akinek csak fizetése van hivatalosan, ott gyakorlatilag nem fordul elő az ellenkezője.

Ennek van egy durvább változata, amikor az illető nem saját zsebre dolgozik, hanem pártkasszára, ez már nevet is kapott a szlengben: alkotmányos költség.

egyrészt sok minden számlamentesen zajlik a világban, van egy fehér, számlás része a forgalomnak, meg egy fekete, számlátlan. És mivel a cégek jelentős részénél mind a kettő van, ezért forog a fekete pénz is, nincs gond, mert van bevétel is feketén meg kiadás is. Csak közben nem fizetik rá az adót meg a járulékokat.

A másik megoldási módszer meg az, ha valakinek olyan szolgáltatásra van szüksége, ami gyakori a piacon, akkor a "támogató vállalat" rendeli meg. Példa: a Párt van éppen hatalmon, ezért gipsz jakab kft. kap megrendelést. Reális értéke 100 forint, lezsírozva számlázhat érte 160-at. Ezek után a Pártnak szüksége van reklámfelületekre, akkor gipsz jakab kft. veszi meg a reklámot. Vagy a Pártnak van valami egyéb célja, akkor a kft ebbe száll bele. Pl. a Pártnak fontos, hogy bajnok focicsapata legyen, akkor gipsz jakab kft elmeroggyant árakon reklámfelületet vásárol a csapat mérkőzésein és abból van a csapatnak pénze. Vagy a Párt közölni akar valamit a néppel, ehhez újságot, tv csatornát tart fenn, akkor gipsz jakab kft. ezekben az újságokban szintén elmeroggyant árakon hirdet.

A túlszámlázási gusztustalanságok közül nem mindegyik adócsalás is egyben. csak a többsége :))) és ezek csak a nyilvánvaló megoldási lehetőségek, amik bárkinek az eszébe juthatnak.

Nem annyira nyilvánvaló algoritmus pl. az, hogy autópályát, művelődési házat, stb. kell építeni. Mondjuk gipsz jakab elnyeri a megrendelést, aminek a reális értéke 100 forint. A kft tudna erre szerezni normális piaci keretek között 10%-ért finanszírozási hitelt. Ekkor 110 forintra kellene pályázni. De nem, hanem lezsíroznak 160 forintos összeget, a kft pedig nem 10%-on, hanem mondjuk 35%-on veszi fel a hitelt. Meg megegyeznek, hogy nem olyan széles útalapot kell építeni, hanem szélesebbet, akkor rögtön a 100 forintos munka papíron 110-120 forint lesz. Felveszi a hitelt, elvégzi a munkát, a Párt kifizeti a bankot, a bank meg a vállalkozót. Ekkor marad 30-40 forintnyi indokolatlan gazdagodás a bankban. Erre a tőkére alapozva indokolatlanul kedvező kamatozású hiteleket nyújtanak a Párt által összeállított vip listákon szereplők számára, amikről mindenki tudja már az elején, hogy be fognak dőlni. De a bankot nem éri kár, mert az építésből ottmaradt zseton meg a bedőlt hitel egyenlege számára pozitív is lehet.

Na, ha holnaptól nem írok, akkor megállt este a nagy fekete autó a ház előtt:) Elvtárs, érted jöttünk, nem ellened....:P

Egyéb: KKV környezetben a mai szerverek bőven elviszik a legtöbb szolgáltatást amire szükségünk van, már elmúltak azok az idők, amikor egy pentium 1-re kellett lesakkozni, hogy nehogy túlterheljük. Kb az egyetlen szempont, hogy ne essen szét túl hamar. :)

Ismerjük már hogy az adott feladat CPU-t, RAM-ot vagy I/O-t zabál, aztán arra veszünk szervert, nem sokat kell mérni. Van olyan task ami csak egy CPU magot és embertelen mennyiségű RAM-ot eszik, az két Xeon X5272-t és 64GB RAM-ot kap. MySQL meg 8 darab SSD diszket mert az szereti ha van I/O bőven. És igen storage-t dd-vel mérünk :)

Azt vesszuk, attol es annyiert, amire a miniszteriumbol utasitas erkezik, es termeszetesen a mi hibank lesz, ha az alkalmazasnak a beszerzett prg/serv/storage nem eleg.
Ez persze indok egy ujabb beszerzesre...
GOTO 1

Azert azt eleg nehez kivitelezni (hacsak nem valami oriasi multiceg vagy) hogy kulonbozo vasakat meg a megvasarlas elott alaposan tesztelgethess a sajat cuccoddal... marad a kis hazi teszt alapjan a specifikacio meghatarozasa, es a gyari adatok alapjan az annak megfelelo - es ar/telj szempontbol legjobb - eszkoz beszerzese.

A'rpi

Szeretnem kerdezni, hogy ez a benchmarkolas hogy mukodik? A gyarto elore odaad vasat, hogy nesze, teszteld? Ha igen, mely itthon is jelen levo gyartok azok, amelyek ezt megteszik, es mekkora cegnek/partnernek kell lenni hozza? Illetve, a felsorolt szintetikus tesztek eredmenyeinek mennyi koze van a valosaghoz?

Szerintem ezeket a kerdeseket kell elobb tisztazni, es majd csak ez utan lehet szavazni erdemben.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

az ibm és kereskedői simán adnak neked vasat tesztelésre. Ha nem valami egzotikus extrát szeretnél, akkor a kereskedő ad a saját szervizkészletéből, ha valami ritkábbat, akkor az ibm.

de dolgoztam már olyan helyen, ahol a hp adott tesztcuccokat egy nagyobb megrendelés előtt.

Nem tudom rá a választ, mert én magánvásárlóként vagy kis cégek képviseletében is megkaptam ezeket a dolgokat.

Szerintem bőven elég, ha elhiszik, hogy komoly a vásárlási szándékod, nem kamu és ki fogod fizetni.

Szerk2: tudok olyan céget is, akitől bérelni is lehet hosszabb-rövidebb időre gépeket, tehát olyan cuccal is lehet tesztelni.

van egy also hatar, mondjuk 200e. Ha 200e -nel nagyobb erteku cuccot nezel ki, es a kereskedo elhiszi rolad, hogy tenyleg akarsz olyat venni, es ki is tudod fizetni, es te meg meg tudod ertetni a kereskedovel, hogy elofeltetel a teszt, akkor lesz probavas. Tul olcso eszkoznel nem eri meg senkinek a teszt, ha a kereskedo nem nez teged komoly vasarlonak, akkor se, es ha a kereskedo meggyoz teged a teszt nelkuli vasarlasrol, akkor se ;)

Tehat akkor ez pofara megy? Mert ez eddig erosen szubjektiv, hogy a "kereskedo elhiszi rolad". Jo, biztos van ilyen, csak szamomra furcsa...
A 200e meg egy vicc, egy normalisabb szerver boven tobbe kerul ennel. Es akkor meg nem is eros vas, csak szerver.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

szervert:
- spec.org specCPU_2006 alapjan
storage-t:
sajat fejlesztesu meroprogram alapjan

Nem tesztelek. Minek? Az applikacio hatarozza meg a szukseges processzor szamot es memoria mennyiseget.
Az applikacio fejlesztoje megmondja, hogy mi kell neki, teszteljen o. O ert hozza a legjobban.

Ha meg elcseszte, akkor veszunk bele. Elobb utobb csak eleg lesz.

Az applikacio fejlesztoje megmondja, hogy mi kell neki, teszteljen o. O ert hozza a legjobban.

nepszeru gondolat, de mind egeszeben mind reszleteiben hamis.
Az applikacio fejlesztoje altalaban nem tudja, hogy a termeke milyen eroforrasokat igenyel milyen kornyezetben. Tudhatna... de nem tudja. Amennyiben a fejlesztonek van fogalma a teljesitmenyigenyrol, akkor is a korabbi, mashol tortent futasok (mint meres) leszurodott esszenciait tudja, ami szuksegszeruen elavult, ha uj hardvert veszel. Bizonyos nagyon komoly;-) alkalmazasoknal a 'fejleszto' csoportba beleertendoak a tesztelok is, esetlegesen van kozottuk teljesitmenytesztelo is (ez mar eszmeletlenul ritka) akkor vannak ugyancsak elavult teszteredmenyek, hogy mit hogyan kell csinalni.
Pl, ha a diszk/storage teljesitmeny kerdeskornek csupan a legelemibb informacioi merheto elterjedest mutatnanak az emberi fejekben, akkor a muninban alapertelmezesben volna disk queu lengh grafikon, de nincs. ('sar -d' -ben avgqu-sz)

A valós életben úgyis inkrementális alapon oldódik meg a dolog, vesznek valamit, kevés, sírásrívás, bővítés, fejlesztés, megnézik, vagy jó, vagy kezdik előröl.