Jeg skal hastighedsoptimere en Java applikation. Den skal performe max på kortest mulige tid. Den kan ikke skalere udad som man normalt ville ønske men kun opad. Det vil sige en enkelt supermaskine med 16 CPU'er og 16G ram i 64bit software. I de senere år er kravet om hurtigere CPU hastigheder er faldet mens kravet om antal CPU'er er steget. Grunden er at en hurtig processor bruger mere strøm end to processorer på den samme kraft og man udnytter altså forholdet mellem ydeevne og forbrug. Problemet med at skalere en Java applikation er først og fremmest at Java ikke kan udnytte en ægte multicore arkitektur så den ønskede effektivitet kan opnås. Man kan tilføre så mange CPU'er man vil men Java kan ikke udnytte dem. Dog kan man sige at sige at Java processerne får mere frihed idet de andre processer på maskinen som fx databaser kan køre på andre cores. Selve Java applikationen er en heterogen monolitisk struktur og den skal eksekveres som en 32bit applikation. Det vil sige at den kun kan udnytte 2G hukommelse eller mindre. Det betyder desværre også at man skalere på den laveste fællesnævner. Men hvad sker der når man flytter en applikation fra en dual core maskine til en ægte fysisk 16 core maskine? Min interesse i sagen er kun henvendt på i hvilken udtrækning Java kan udnytte de mange processorer. Hvis Java kun kan udnytte en processor må applikationen kunne køre på samme vis som på andre duals maskiner. Hvad ville der ske hvis Java kunne udnytte flere CPU’er og de enkelte processer udsættes for ægte samtidighed, altså potentielt mange samtidige eksekvererne tråde i samme objekt? To ting vakte min opmærksomhed. Dels en memory leak og dels en slags forvirring omkring konfiguration og resourcer som fx databaseforbindelser. Memory leaks i applikationen skyldes bla ikke frigjorte værdier fra hukommelsen. Den andre adfærd var mere underlig. Applikationen kunne køre skiftevis langt før en tilstand reageret på manglede resourcer. Til min store overraskelses opdager jeg efter flere timers debug session at problemet ligger i ThreadLocal objektet i Java eller rettere dem måde man bruger dem på. Applikations designeren binder databaseforbindelser i disse tråd relaterede objekter. Når en container tråd dør tager den de lokale objekter med sig. Men når 64bit maskinen bestemmes sig for at skifte CPU mister alle threadlocals konteksts. Det betyder at konfiguration og resources bliver frigivet midt i kørselen. ThreadLocal har været en meget brugt strategi gennem mange år og benyttes til at bære fx et ID gennem en applikation både i en tråd men jeg vil påstå at det er et antipattern at benytte den til andet fx databaseforbindelser. læs: Thread-local storage Efter udbedrelse af problemerne køre softwaren fint på 64bit maskinen. Java installationen bruger to, måske tre CPU'er til at eksekvere Java softwaren. Når man skalere er det ønskeligt at kunne skalere lineært, altså ved en fordobling af kraft forøger man hastighed gange to. Reelt set køre denne Java applikation på en af de 16 hurtige CPU ad gange og udnyttelsen af den fine hardware stinker max. Hvis man vil kunne skalere sine applikationer må man skrive dem til multicore. "Small Things, Loosely Joined, Written Fast":posts/122-Small-Things-Loosely-Joined-Written-Fast 2008-11-01T09:51:34Z 124 124 true 45 2008-11-02T22:50:31Z Den perfekte storm er en storm som præcis kan overvindes uden alvorlige komplikationer til følge. Indenfor aktiehandle forsøger man at bygge systemer der kan håndter virkeligt mange handler på kort tid. For en capture virksomhed betyder det liv eller død at deres systemer kan gennemføre 150.000 handler i sekundet og alle under 5 millisekunder. Samtidig stiger efterspørgsel eksplosivt. Derfor kan de kun overleve hvis deres systemer er bygget til at kunne håndtere fremtidige krav. Altså en perfekt storm på deres system. Det er den form for udfordringer vi står overfor i den parallelle computer verden. Hvis vores systemer bliver belastet mere end de kan klare bryder de samme. Det sker at en forretning opnår virkelig stor succes og får dermed nye problemer med at klare efterspørgselen. For ledelsen betyder det at de må opmande på alle vigtige poster lige som IT afdelingen skal kunne skalere både hardware og software. Man taler om lineær skalerbarhed. Linear skalerbarhed har en enorm indvirkning på omkostninger for enhver virksomhed. Denne egenskab vokser betydeligt i applikationer som er basset på on-demand-prissætning. De fleste systemer, især klassiske n-lags arkitektur kan ikke skalere lineært. Linear skalerbarhed betyder, at systemet er i stand til at øge sin kapacitet i en lineær relation til mængden af ressourcer der tilføres. Fx hvis en server kan behandle 50 transaktioner i sekundet, to servere kan behandle 100, ti servere kan behandle 500 og så videre. Ikke-lineært skalerbare systemer står over for faldende kapacitet for hver supplerende tilvækst. Så mens den første server kan behandle 50, to servere kan kun behandle 85, tre servere vil behandle 110 og så videre. På et eller andet tidspunkt vil et ikke lineært skalerbart system opleve at tilførte ressource ikke giver ekstra kapacitet. De almindelige årsager til dette omfatter database forbindelser og låse, persistens og transport mekanismer for messaging middleware og ESB. Erfaring siger at traditionelle arkitekturer dvs. n-niveau applikationer ofte står overfor denne påstand. Amdahl's lov giver os en formel til at beregne hvilken effekt forskellige ting som påvirker vores evne til at skalere. Applikationer kan modsvare flere forskellige egenskaber. Fx kunne man forud set en vis succes og bygge derefter. Nogle brancher skal kunne klarer en ekstra kapacitet på 4000% pr år. Andre applikationer er brygget til at kunne klare spidsbelastning. Man kan opnå ekstra skalerbarhed gennem ved at designe systemet på en anden måde, skriver udvalgte dele om eller omdefinere systemets arkitektur. Måske er præmisserne for systemet omdefineret og man må tilpasse systemet til de nye præmisser. Et vigtigt punkt er valg af hardware, ofte er de trufne valg meget konservativt og basset på rutine frem for bevis. Men i alle tilfælde vil det betyde økonomisk katastrofe. De økonomiske aspekter skal holdes oppe imod hvad system-nedetid koster og hvad betyder det at være uden oppetid i en time, et døgn? Kan virksomheden overleve? I vores medie tider er fejl lig med pressebevågenhed. Hvor risikovillig er virksomheden på dette område? Langt de fleste IT systemer jeg har set kan slet ikke skalere. Ofte skyldes det ikke dårlige teknologi valg men blot ligegyldighed. Teknologien er valgt på forhånd af folk som dårligt kender de essentielle krav til systemet eller til forretningen. Desværre er skalerbarhed først noget der dukker op efter en mere end "The Perfect Strorm" 4 2008-08-29T02:00:00Z 117 117 false 45 2008-08-29T02:01:50Z Jeg har lige hørt John Davies for syvende gang over de seneste år og det er altid en fornøjelse. John er en world wide veteran indenfor IT konferencer og har været aktiv konsulent siden c programmeringssproget var state of the art. Gennem årerne har han haft adskillige store stillinger og firmaer med specialer som (SWIFT, FpML, ISO-20022. osv). John taler om investeringsbanker og alle de udfordringer som de møder såsom, ekstrem hastighed, reaktionsevne og absolut garanti. Garanteret garanti aspektet bliver sat i alvorligt perspektiv når en vendor bliver holdt til ansvar for hver og eneste besked, lidt af en mundfuld når man tænker på at en SWIFT besked med udligning af kontobeløb mellem landekonti er på samme beløb som en vendor er værd og der bliver sent nogle hundrede om dagen. Når man arbejder med investeringssystemer betyder reaktionstid og hastighed alt. Systemerne er sat op til at gennemføre handler ved meget præcise udregnede grænser og hvis disse systemer halter blot 10 millisekunder i forhold til de andre investeringssystemer er det dem der løber med de gode handler. Det er ikke for sjov at alle de store investeringsforretninger ligger tæt placere op ad hinanden og enkelte endda direkte ovenpå børsen i London. Investeringsforretningerne ligger også i umiddelbar nærhed af de største backbones for at hindre at eventuelle routere stjæler den vigtige beslutnings tid. I forhold til traditionelle systemer er disse også specielle på en anden måde. Deres maximale respons tid er måske nede på ca. 3 millisekunder og det sætter spørgsmål som "vil du købe MS aktie nu" i relief. Ethvert spørgsmål skal behandler enorme mængder af data inden det er muligt at svare. Det er mere normalt at man loader alt data ind i memory om morgenen og gemmer for lang tid arkiv om aftenen efter handlerne er overstået. Ydermere kan der arbejde ofte flere tusind mennesker på selvsamme systemer. Det kræver en fornuftig planlægning og køligt overblik at have så mange programmører til at arbejde sammen ude en direkte samhørighed. Service stak I flere foredrag taler John også om den software stak der fortrækkes i de banker hvor hans virksomhed er tilknyttet. Denne gang sagde han at Applikation servere er for nedadgående i den slags banker. Det har længe været sådan at man ikke må benytte EJB fordi de er langsomme og ikke persistent nok. John er glad for teknologier som GIGAspaces og Java Spaces. Enlig ville jeg gerne skrive lidt om SWIFT formatet. Men det bliver nok først om lidt. I det gamle Javahouse arbejdede vi for en bank med SWIFT formatet. Jeg ville ønske vi på det tidspunkt have set det SWIFT API som John har lavet i sit firma, C24. 11 2008-01-31T05:15:00Z 96 96 false 45 2008-02-06T04:31:11Z Hvis din objektmodel er replikeret over flere VM'er, så er sandsynligheden for at alle crasher samtidigt, lige så lille som at DB's diske crasher. Så kan man rent faktisk arbejde med crash-tolerant memory og antage at heap'en aldrig slettes. Det fjerner hele behovet for et data-access layer, for applikationens model er jo crash-resilient. Det betyder at man kan droppe databasen og bruge memory i stedet. Halvdelen af alle framevorks i Java handler om O/R mappingsproblemet og der er skrevet indtil flere design patterns som attakere netop dette problem som fx valuebean(VB) og datatransferobject(DTO) der er strukturelle mønster. Enlig er det en ret enkelt og ligetil proces. Problemet er at det er trivielt og at vi i mange år skrevet tusind af klasser som gør præsis det samme. En såkaldt serverside programmør lever af at mappe tabeller og relationer i databasen til en objektmodel til trods trods for at tabeller og objekter er to vidt forskellige konstruktioner. Firkantede database tabeller passer ikke lige over til et rent objektorienteret paradigme. Et par gode kolleger fra Javahouse tiden og jeg selv, inviterede Owen Taylor til Danmark for at tale i et par banker og i cybercomgroup headquarter. Owen er specialist i Giga Spaces teknologien. Det helt essentielle ved Spaces er hastighed og skalerbarhed. Men i tilgift får man en sjov afledt effekt. Et typisk forløb er at man preloader en mængte data fra databasen om morgenen hvorefter arbejdet begynder. Efter arbejdet kan man evt. gemmer nye data. Resten af tiden benyttes kun memory. Alle objekter er persistente og replikerede. Eneste logiske grund til at opdatere databasen er at interaktion med legacy systemer. Selve spaces er aldrig nede. Den helt store fordel er at man kan fjerne hele databasen og alle de gamle problemer med O/R mapping og hele dataaccess layer i den gammeldags software model. Der er fortaget undersøgelser som viser at backend programmering(O/R mapping) tager ca. 60 procent af alt udviklingstid. 13 2007-08-14T00:12:00Z 59 59 false 45 2008-04-08T07:29:18Z Take A Look at the SpaceFacade Pattern, Owen Taylor of GigaSpaces discusses how space-based architecture is fundamentally different from traditional architectures and how it supports the potent pattern, Master/Worker. He addresses state management, event distribution, performance, reliability and interoperability. <a href="http://go.techtarget.com/r/1245074/5224861"> here </a> Vil du sælge dine Microsoft aktier lige nu? Eller vil du helle købe flere? Dette valg har meget at gøre med den historiske baggrund for netop denne aktie. Som minimum vil du sikkert gerne vide hvilken pris de sidst er handlet til, og måske vil du også gerne vide hvordan udviklingen har været de sidste 6 måneder. Måske vil du oven i købet vide om Microsoft i nærmeste fremtid er ved at lancere et nyt styresystem. Hasta la vista, Baby! Lad os antage at du har 5 millisekunder til at finde ud af det! Og lad og lege at der samtidigt med dig findes ca. 5000 andre som stiller sig det samme spørgsmål netop nu! Tja,, du vil ha lidt svært ved at overskue det hele. Det vil langt de fleste systemer også. Men der finder en specielle systemer der kan klare opgaver af denne art. Systemer bruger udelukkende indenfor pengehandle og militær. Disse systemer har det til fælles at de skal virker hurtigere end alle de andre system af samme slags. Det er maskinerne som bekriger hinanden når der handles værdipapirer. De arbejder så hutigt at de ikke har tid til databserne som jo normalt ellers holder på data. De skal være super robuste og være klar til at reager nå som helst. De skal kunne regenerer sig selv og være voldsomt skalerbare grundet kraftige spidsbelastninger. Den slags applikationsegenskaber kan opnås ved brug af et space. GigaSpaces er et system på benytter den teknologi. Et space kan betragtes som en fælles hukommelse alle kan deler. (red, fluffy cloud) En klient sætter et object ind i spaces og derefter kan alle bruge det. Interfacet ind til spaces er meget simple. Det består kun 4 metoder(CRUD). I space lever objekter og kan deles umiddelbart efter de er initialiseret. Man deler typisk metoder og beskeder. Events er beskeder. Denne model fravælger fuldstændigt den traditionelle tier model. Den beskriver ingen logisk opdeling(layering) af applikationen men rekomendere POJO. I traditionelle løsninger er multilayer modellen meget brugt. Den skulle måske afløses af POJO's men det har lange udsigter. Næsten alle laver stadig gammeldags layering selvom mange nye frameworks ikke fordre denne opdeling. Selvfølgelig kan man opdele sin applikation i fysiske lag, specelt hvis man har en virkelig god grund. I mange år har vi alle lave disse lag på baggrund af en tegning fra SUN. Den viser denne lagopdelte model hvor man ikke kan se andet en tekniske komponenter. Halvdelen af disse komponenter var EJB 2.x. og skulle naturligvis gemmes bag stateless facader. Heldigvis er EJB ikke EJB mere efter 3.x specifikationen men blot trasaktionellen komponenter. De objeker som kom ud af facederne var value-objecter(dto), men dem behøver man heller ikke mere. Hvorfor skal vi så blive ved at bygge alle de lag? 13 2007-03-01T12:04:00Z 26 26 false 45 2008-04-03T09:18:13Z