Reuters: By the (milli)second
Thomson Reuters er et kanadisk multimediaselskap med HQ i Toronto, har kontorer i hele verden og er en av verdenslederne innen informasjonsformidling. Kundene av Thomson Reuters Point Carbon inkluderer banker, tradere, porteføljeforvaltere, selskaper og myndigheter; kort sagt alle med behov for dyp innsikt på tvers av karbon-, forsynings-, olje-, gass- og industrimarkedene. Data fra mange ulike kilder innhentes, behandles og berikes ved å ses i sammenheng. Prosjektet gikk ut på å tilgjengeliggjøre utsnitt av dataene for klienter på en rask og effektiv måte.
KodeWorks ble engasjert hos Reuters for å bidra i utvikling av et nytt web-grensesnitt for tidseffektive klientforespørsler om prognoser på energidata. Sammen med en prosjektleder fra Thomson og to utviklere fra et annet konsulentfirma
Når millisekundene teller
Oppgaven fra Reuters var “enkel”; make it faster! I denne bransjen kan millisekunder være forskjellen på store tap eller heftig gevinst. På tidssensitiv informasjon av ulike typer finansielle transaksjoner var målet near-realtime nivå. Stor kunde, klare instrukser og store økonomiske betydninger for det man leverer, kan slå ut høyt på stressfaktoren.
Store utfordringer, kan også bety gode utfordringer. En god strategi og ledelse kan løse det meste. Eirik Larsen som var vår mann på jobben forteller at det mest positive med prosjektet var at gjengen i Reuters var mennesker med skikkelig driv og passion for faget. Dette har stor betydning for prosessen. Om ikke man fikk løst problemene ved skrivebordet og tastaturet, kunne det komme et godt forslag ved kaffeautomaten; “Hva om vi kun bruker 8-bits integers til å lagre disse flyttallene? Hva om vi vurderer delta-lagring av tidspunkt? Hva om vi bygger indeksen basert på disse feltene i stedet?”
Vi opprettholdte strikt kontroll på belastningen tjenesten var utsatt for til enhver tid, og sørget for å videre-henvise nye forespørsler dersom belastningen var for høy. Det var også svært viktig å minimere tiden fra en klientforespørsel traff webgrensesnittet til et svar ble servert. Svar bestående av et mindre antall bytes kunne serveres direkte, mens større svar skulle streames, på bakgrunn av klientens preferanser. Dette førte til at alle steg i pipeline ned til datalaget måtte optimaliseres.