Titlen på denne post har jeg snuppet fra et ”white paper” om hastighedsoptimeringer i forskellige J2e applikationsserverer. For nogle år tilbage stod den helt store kamp på applikations markedet mellem ret enkelte egenskaber såsom hastighed, kapacitet eller robusthed. Denne gang har jeg kun fokus på hastighed og specielt en applikationsserver har forsøgt at markere sig som den absolut hurtigste. Under udviklingen nedsatte de nogle gruppe som udelukkende koncentrerede om at finde og afhjælpe hotspots for at finde yderligere hastighed. Under denne arbejdsindsats fandt de på mange tricks og metoder man kan gøre for at optimere både selve serveren men også i de applikationer som hostes af serveren. Konklusionerne er omfattende og komplekst men en enkelt tese munder ud i denne sætning: ”Det koster mere at skabe en ny instans af en klasse, end det koster at have en instans og lave et antal kopier.” Det konkredte problem er at jeg har et ”Command Pattern” der har indkapslet et beregningsmodul. En hver beregning er isoleret og kan leve uden sideeffekter eller delt hukommelse under afvikling. Det uheldige er at beregningerne er koblede gennem et lag med serialisering/deserialisering. Som serialisering tool er valgt XMLBeans og mere end 95 procent af tiden går med at instantiere XMLBeans objekter. Det er ikke et problem jeg vil løse ved at konstruere en ny applikationsserver men blot bruge samme analogi. Jeg har med succes implementering metoden flere gange og fundet betragtelige hastighedsoptimeringer. Hemmeligheden er hotspot compileren. Jeg vil ha hotspot til at clone objekter fremfor at new objekter. Metoden provokere hotspot til at lave effektive genveje melle bytecoden og basic CPU instruktioner. <pre> /** * Static references optimizer * @see http://en.wikipedia.org/wiki/Java_bytecode */ class StaticReferencesOptimizer { private static XMLBean xmlbean = new XMLBeansDummey.create \AllBeans(); } </pre> Ved applikations start vil disse notificeret beans blive instantieret og ved service kald vil compileren blot lave en kopi. Millionvis af kopier med 90 til 95 procent bedre hastighed end ved at lave nye instanser. Det var alt. Alle de XML beans som skal benyttes skal ind i sådan en klasse i en statisk kontekst og den hastighedsoptimering du kan opnå ved så simpelt indgreb vil overraske dig. Selv om dette trick er utroligt enkelt er det langt fra alle mainstream Java programmører som forstår de mekanismer som sker i hotspot compileren. Og heldigvis for det. Fra Java's perspektiv ses en klasse som ikke har referencer til eller fra andre klasser. Det mest normale er at en novice programmør sletter filen. Her kommer disciplin og dokumentation ind i billedet men det er en anden sag. 2009-02-01T04:38:56Z 133 133 true 37 2009-02-01T08:08:52Z Something is not working, yaaaa i know. I finally pulled myself together to a total rewrite on my website. I do not have time enough to do it for real, but anyway. Don't ever do total rewrites in software development! Yaa I know. But, i have to rewrite everything to be completely restful. All services is now running full REST mode. Representational State Transfer. h4. Old services This mens that a few services not are working anymore like fx Atom protocol, RSS feed are all gone. I am sorry. Temporary I have a method caching all calls the old services like this. It returns an 301 and a new location. Don't know if this works whit google? We will see. <pre> def redirection render :text => "Moved Permanently!", :status => 301, :location => '/posts' end </pre> I got a problem. Google is still pumping the googlebot spinder robot on my pages. So I will try something else and see if I can keep google out. <pre> def redirection render :text => "Gone", :status => 410 end </pre> h4. Representations All services can return more than one representation. Services deliver Javascript, JSON, XML and pure HTML. h4. Feeds The new feed address are: http://www.frankvilhelmsen.com/posts.atom or http://www.frankvilhelmsen.com/posts with the content-type set to atom h4. REST API * "curl -i -X GET -H 'Accept: text/html' /posts/1 ":/posts/1-My-new-website- * "curl -i -X GET -H 'Accept: application/js' /posts/1 ":/posts/1-My-new-website-.js * "curl -i -X GET -H 'Accept: application/xml' /posts/1 ":/posts/1-My-new-website-.xml * "curl -i -X GET -H 'Accept: application/json' /posts/1 ":/posts/1-My-new-website-.json * "curl -i -X GET -H 'Accept: application/atom+xml' /posts/1 ":/posts/1-My-new-website-.atom h4. REST Nouns This page has nouns like fx /posts /comments or /titles. h4. REST Verbs All nouns can bee accessed with GET verb. Note that there are restrictions on all PUT, POST and DELETE verbs. This output are the rake routes command in rails 2.0.2. <pre> GET /posts {:controller=>"posts", :action=>"index"} formatted_posts GET /posts.:format {:controller=>"posts", :action=>"index"} POST /posts {:controller=>"posts", :action=>"create"} POST /posts.:format {:controller=>"posts", :action=>"create"} formatted_new_post GET /posts/new.:format {:controller=>"posts", :action=>"new"} edit_post GET /posts/:id/edit {:controller=>"posts", :action=>"edit"} formatted_edit_post GET /posts/:id/edit.:format {:controller=>"posts", :action=>"edit"} post GET /posts/:id {:controller=>"posts", :action=>"show"} formatted_post GET /posts/:id.:format {:controller=>"posts", :action=>"show"} PUT /posts/:id {:controller=>"posts", :action=>"update"} PUT /posts/:id.:format {:controller=>"posts", :action=>"update"} DELETE /posts/:id {:controller=>"posts", :action=>"destroy"} DELETE /posts/:id.:format {:controller=>"posts", :action=>"destroy"} </pre> When you call the old RSS or Atom protocol something like this happens. Replay with 301 Moved Permanently and u get one new header Location to hit. <pre> frank@howdy:~\> curl -I -X GET localhost:3000/feed HTTP/1.1 301 Moved Permanently Connection: close Date: Sun, 13 Jan 2008 17:39:42 GMT Set-Cookie: _blog_session=BAh7BiIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNo%250ASGFzaHsABjoKQHVzZWR7AA%253D%253D--830361ac99d21fe1231dde1ab3fc6f515599537d; path=/ Status: 301 Moved Permanently Location: /posts.atom X-Runtime: 0.00239 Cache-Control: no-cache Server: Mongrel 1.0.1 Content-Type: text/html; charset=utf-8 Content-Length: 18 </pre> The content are maybe changing a bit, but what the hell, you will live. I hope that you will be some what provoked by the content and you are most welcome to comment. For the most part I write about stuff that I find stupid or just something around my job as software developer. I feel myself inspired from cssgarden website and want to fix it together with static and dynamic content and test out some ajax components. A few funny links * "Google fight":http://googlefight.com * "Labs google com":http://labs.google.com * "Goggles":http://www.isoma.net/games/goggles.html 12 2008-01-10T13:57:00Z 1 1 false 37 2008-02-15T04:38:21Z XML har været på banen I lang tid nu og er blevet brugt til næsten alt. Faktisk en hel del mere end det var beregnet til. XML er godt til noget og noget lort til andet. * XML er velegnet til tekstredigering * XML er tålelig til at beskrive hierarkisk data. Brugen af start og slut tags gør det ret larmende, specielt hvis der kun bruges elements frem for attributter for simple værdier. Standarden overvejer dog de negative sider * XML er frygtelig for programmeringssprog. Når XML bliver en del af kontrol strukturen i programmeringssproget går det helt galt og XML bliver ulidelig at arbejde med Umiddelbart kan jeg forstå at man benytter XML til udveksling af data mellem forskellige institutioner som er fysisk adskilt og jeg glæder mig også over at høre om løs kobling mellem systemer. Der hvor vi efter min mening fejler er når vi aftaler en protocol gennem en WSDL fil og derefter autokompilerer både vores afsender og modtager system. Nu har begge parter samme nye problem. De skal forsøge at mappe deres eksisterede data til den kontrakttuelle grænseflade. Så hvad har vi vundet? En god ting er at vi har flytte problemdomænet tættere på vores organisation, hver især. I udviklingsprocessen er det vigtig at man kan arbejde tæt sammen lokalt. Forretningen og udviklerne kan arbejde i samråd. Vores udgangspunkt var et klart ønske om løs koblede systemer hvor man kan ændre delapplikationen uden implikationer for andre dele af systemet. Desvære er vi nu endt i fastbundnet system hvor enhver ændring skal gennemføres som en sektor løsning med deploy politiker og alt hvad der medfølger. Hvordan kan det være? Hvordan bygger man robuste system som kan ændres tilhver en tid uden at skabe problemer for resten af applikationerne? Svaret er enkelt: Det kan vi ikke. Vi kan ikke bygge systemer som både er distribueret og monolitisk. 13 2007-08-20T05:59:00Z 60 60 false 37 2008-04-08T07:29:54Z Det var Dave Thomas der under en tale på RubyConf i London udtalte de berømte ord som senere skabte det mentale fundament der nu forstås ved ducktyping. "If it walks like a duck and quacks like a duck, it must be a duck" Ikke mere pjat men direkte til koden: <pre> class Elephant { wash_dish() {} } class Man { taking_a_nap() {} } class Woman { wash_dish() {} } </pre> Tre klasser der på udemærket vis repræsentere et stykke virklighed. Det er "design by capability" og nogen vil sikkert nikke genkendende til de egenskaber der er langt vægt på. Hvis jeg som bruger af disse klasser og skal have hjælp med opvasken, kan jeg kalde metoden(wash_dish) på hver af de tre instanser. Kun de to besidder evnen til at hjælpe mig. Manden lader jeg sove, ingen grund til at smide en exception af den grund ham. * "Duck typing er at bruge objekter ud fra deres adfærd og ikke deres type" I dynamiske programmeringssprog kigger man altså ikke på klasse typen men mere om de har den ønskede affærd i form af metoder. WS-duck-typing er lidt det samme dog uden programmeringssproget. Men hvad har de kornfede ænder i det hele tage med webservices af gøre kunne man spørge? Jo det bunder i en fælles holdning hos medlemmerne af "http://soa-manifesto.org":http://soa-manifesto.org og hos mange andre software trendssættere. * "Service orienteret software er det rigtige at stræbe efter og Service Orienteret Arkitektur(SOA) opstår som afledt effekt af service orientering" Med andre ord er de alle enige om at SOA som princip er godt for alle service orienteret applikationer men de er også samtidig enige om at SOAP og andre WS* (dødsstjerne teknologer) stinker. Det viser sig at WS-duck-typing er en fin måde at udveksle information på, endda mellem meget forskellige systemer. Det essentielle ved en webservice er at dele information og så længe den går som en and ,,,, osv Der er lidt forskellige meninger omkring hvor mange, eller rettere sagt hvor få steps der skal til for at skabe webservice docktyping. Jeg bruger den lette model der består af tre enkle skridt. # Validere ikke indkommende beskeder. # Brug XPath til udtrækning af information. # Generer aldrig stubs og skeletons. 1. Validere ikke indkommende beskeder. Der ingen som gider bruge tid på at validere dine beskeder. Der er heller ikke noget som gider definere dem, opdatere dem eller overholde dem og de sætter unødigt meget fokus på maskinkraft. Har du nogen sinde set en komma separeret fil med typer? Her kommer det næste citat fra Postel lov: * "be conservative in what you do; be liberal in what you accept from others" 2. Brug XPath til udtrækning af information. XPath er en fremragende måde at udtrække information fra et XML dokument. Kode skrevet fra XML API'er er ofte for urobust når det kommer til element ordning, nestede fragmenter og ikke forventede elementer. Når man bruger XPath opdager man ikke hvilken orden elementer kommer i ej heller om det er første eller andet element. De tider hvor XPath var langsom er over. 3. Generer aldrig stubs og skeletons. Det er med sikkerhed det mest kontroversielle punkt af dem alle. Hvis du opretter flere klient side "stubs" eller flere server side "skeletons" i et typet sprog som Java, mister du muligheden for at være liberal omkring dine XML beskeder. Til trods for at SOA WS produkt sælgerne påstår at du er løs koblet systemer har du med den fremgangsmåde oprette et stærkt typet API der ovenikøbet er stærkt bundet til WSDL kontrakten. Hvis en af disse parameter ikke findes, er forkert forkert type eller der er indsat en ekstra kommentar vil informations udvekslingen fejle. Anbefalingen lyder på at behandle web tjenester som XML beskeder i stedet for RPC kald. På den måde kan man skabe XML services der er mere fleksible og interoperable. 13 2007-02-25T13:20:00Z 21 21 true 37 2009-10-28T06:18:50Z