nrk.no

Opne og frie data blir bomba i stykker

Kategorier: Internett & Nettjenester


Oppdatering i juli 2012: Vi har konkludert med at vi truleg skal innføre eit nøkkelsystem på yr.no, met.no m.m.; men systemet er ikkje laga og vi veit førebels ikkje når det vil bli implementert. I juli 2012 gjekk vi over til å kæsje innhaldet vårt via Akamai, og dette har gjort at den tekniske drifta har stabilisert seg og at vi har fått flytta mykje av trafikken ut av nettverka til NRK/met.no.

yr.no har eit av dei mest omfattande frie data-tilboda i Europa. NRK og Meteorologisk institutt har vald å frigje vêrdata på ein svært open måte: det er ingen krav til registrering, nøklar e.l. No står tilbodet i fare for å bli «bomba» i stykker av utviklarar som skriv dårlege testscript eller Android-applikasjonar som hentar usannsynleg store datamengder.

Gratis vêrdata frå yr.no

Alle varsla på yr.no er òg tilgjengelege i XML-format. Ved å bruke XML-formatet kan utviklarar (programmerarar) og andre laste ned data til bruk i applikasjonar og nettenester.

Tilbodet er svært omfattande: Ei  kan få varsel for alle 8,3 millionar stader det er varsel for på yr,no, i tillegg er alle observasjonar frå målestasjonane til Meteorologisk institutt fritt tilgjengelege.

Les meir om vêrdatatilbodet på www.yr.no/verdata

I 2007 gjorde Meteorologisk institutt eit svært modig og revolusjonærande vedtak: Så å seie alle vêrvarsla skulle bli gratis og fritt tilgjengeleg for ålmenta. Instituttet etablerte yr.no saman med NRK, og tilbodet om gratis vêrdata er ein av forklaringane til kvifor yr.no i dag er blant dei største nettstadene i Skandinavia.

Modellen for korleis vi valde å frigje dataene var svært enkel: Alt skulle vere heilt ope, det skulle ikkje vere krav til registrering, og alle skulle få lov til å bruke dataene til nett kva dei ville utan å spørje om lov fyrst.

Både Meteorologisk institutt og NRK er sikre på at denne politikken framleis er rett: Alle som vil skal kunne hente og bruke data.

Vêrdata-tilbodet er svært populært: Det siste året har det i snitt blitt lasta ned ca 10 millionar XML-filer kvar dag, i tillegg til opp mot 8 millionar sidevisningar kvar dag på nettsidene. Det er òg mange som brukar RSS, JSON o.s.v.

Lastar ned enorme mengder data som ingen ser på

Dei siste månadene har bruken av vêrdata-tilbodet auka ekstremt. Vi tykkjer det er bra at mange tek i bruk datagrunnlaget, og til no har vi berre sett inn fleire maskiner for å ta unna trykket. Problemet no er at bruken aukar ekstremt mykje, og at dei som lastar ned mest data ikkje brukar dataa dei lastar ned til noko som helst.

Når vi har gått gjennom loggane for kven som lastar ned mest data frå yr.no ser vi at listene blir toppa av to typar tenester:

  • Android-applikasjonar som lastar ned vêrdata i bakgrunnen, og som lastar ned nye varsel kvar gong du har flytta deg til ein ny stad og/eller lastar ned nye data på faste tidspunkt sjølv utan at brukaren ser på varselet. D.v.s. at applikasjonen lastar ned ca 50 varsel kvar dag, sjølv om brukaren truleg berre ser på eitt av dei.
  • Testapplikasjonar / nettstader under utvikling o.l. Ca halvparten av IP-adressene som «bombar» yr.no med førespurnader ser ut til å vere interne testprosjekt, utan at data som blir lasta ned blir vist for publikum.

Det er svært få av tenestene/applikasjonane som lastar ned data frå oss som skapar problem. I dei få tilfella der vi får problem, er det snakk om tenester som f.eks. lastar ned varsel for 10 000 stader samtidig, gjerne på runde klokkeslett. I dag går yr.no ned relativt ofte i nokre sekund kvar heile time på grunn av slik «bombing»

Konsekvensane av dette er at både nettstaden yr.no og det opna datagrunnlaget er truga: ved at store mengdar data blir lasta ned heilt føremålslaust, kan hovudtenesta og api-et bli overbelasta slik at vi ikkje klarar levere vêrvarsel til nokon.

Korleis sikre at både yr.no og at datagrunnlaget framleis vil vere både ope og tilgjengeleg?

Vi ser at vi er nøydd til å gjere «eitt eller anna» for å sikre at datagrunnlaget framleis skal vere ope og tilgjengeleg for alle. Spørsmålet er kva tiltak som fungerer best, og her treng vi innspel og hjelp frå brukarane av yr.no og andre kloke hovud.

Eitt forslag som har vore diskutert er å innføre obligatoriske nøklar for å hente data. Nøklane kan anten vere dedikerte subdomene per brukar eller eit parameter i URL-en når ein hentar data. I fyrste omgang har vi ikkje lyst til å krevje at XML-brukarane må registrere seg med namn og e-post, sjølv om dette sjølvsagt gjer det enklare å få kontakt: vi har lyst til at ein skal kunne bruke data frå yr.no utan å fortelje korkje NRK eller Meteorologisk institutt kven ein er eller kva ein har tenkt å bruke dataa til.

Dei fleste andre tenester som tilbyr gratistilbod a la yr.no har omfattande registrering i dag. For å få bruke kart frå Google Maps må ein f.eks. ha ein Google-konto, i tillegg til at ein må oppgje nøyaktig rot-URL til  nettstaden karta skal brukast på. Vi tykkjer i utgangspunktet at dette er for omfattande registrering; i tillegg krev det eit omfattande supportapparat for alle som har gløymd passord eller har andre problem.

Ved at alle som hentar data frå oss må ha ein unik nøkkel, kan vi sperre tenester eller applikasjonar som lastar ned uhorvelege mengdar data. Vi har sperra enkelte IP-adresser i dag, men ser at IP-sperring i seg sjølv ikkje er nok til å stanse f.eks. mobilapplikasjonar som går bananas.

På sikt ser vi for oss at vi kanskje kan innføre automatisk sperring dersom ein nøkkel lastar ned meir data enn ein definert kvote for kvart 5. minutt. Ei slik sperring kan f.eks. gjelde for seks timar, lenge nok til at utviklaren oppdagar at han har blitt sperra.

Det er mange ting vi lurar på:

  • Er eit slik nøkkelsystem ein god idé, eller finst det andre enklare og mindre byråkratiske måtar å oppnå det same på? Er subdomene eller URL-parametre den beste løysinga?
  • Korleis unngår vi at folk brukar andres nøklar?
  • Blir datagrunnlaget mindre fritt ved at vi innfører nøklar? Vil det vere vanskelegare å ta det i bruk?
  • Korleis sikrar ein på best måte at offentlege data faktisk er fritt tilgjengelege, utan at dei blir «bomba» i stykker av meingslaus trafikk?

Har du innspel eller gode råd? Skriv ein kommentar!

87 kommentarer

  1. Eirik Stridsklev Nilsen

    Innfør nøkkel – nøkkel skaffes ved en enkel sign-up, i prinsippet trengs en tvungen CAPTCHA, frivillig epostadressefelt og en submit-knapp. Yr.no forbeholder seg i brukervilkårene retten til å sperre/strupe enkeltnøkler ved misbruk/feilbruk, og dersom utvikleren ønsker å bli informert må han/hun oppgi epostadresse.

    Fritt er vel og bra, men praktisk gjennomførbart er bedre. I ytterste konsekvens kan sløv utviklerpraksis føre til at Met må bruke mer penger på hardware og mindre penger på tjeneste.

    Svar på denne kommentaren

  2. Først og fremst: så kjipt at dette har blitt et problem! Om ikke innholdet blir mindre fritt hvis man krever API-nøkler, blir terskelen for å komme i gang litt høyere.

    En helt konkret ting som kunne vært gjort er kanskje å jobbe litt med cache-kontroll på sidene? Jeg ser at XML-varsel-sidene (f.eks. http://www.yr.no/stad/Noreg/Telemark/Sauherad/Gvarv/varsel.xml) leveres med HTTP-headere som:

    * Cache-Control: max-age er ett minutt
    * Expires og Last-Modified følger tilsynelatende samme «policy»: Expires er ett minutt etter Last-Modified
    * Ingen ETag

    I tillegg ser jeg ingen spor etter at det står en cache-server foran sidene? Jeg vet ikke hvor kostbare IIS-«workerne» deres er, men de er vel antakelig en del tyngre enn f.eks. enn de ville vært med Varnish. Spesielt vil vel mobiltelefoner på et tregt nettverk (som de fleste mobiler er, spesielt når folk er på farta) holde kostbare IIS-ressurser opptatt med å levere data den tida det tar å få sendt alt innholdet til mobilen i andre enden.

    Svar på denne kommentaren

    • Håkon Erichsen (svar til Erik Bolstad)

      For å adressere problematikk i forhold til koordinater og caching: Kunne det vært en idé å splitte opp koordinat-værsøk i to? Ha et kall som kun oversetter koordinat til sted, og et nytt kall som henter været for dette stedet (sistnevnte har dere jo allerede: varsel.xml). Dette gjør ting litt mer klønete for programmerene, og man vil få dobbelt så mange kall for denne typen spørringer. Men til gjengjeld er det første kallet (som er vanskeligst å cache) utrolig lite, og «workloaden» flyttes over på varsel.xml, som dere allerede cacher.

      Du kan altså få ett lite kall som er litt vanskelig å cache* og ett stort kall som er veldig lett å cache, istedenfor ett stort kall som er veldig vanskelig å cache. (*Man kan kanskje få noe uttelling på å cache koordinat->sted kallet til tross for at koordinater er veldig finkornet: da koordinat->sted endrer seg veldig, veldig sjeldent kan cache-tiden være veldig lang, noe som burde kunne gi cache-treff etterhvert som cachen fylles opp. Men dette er uansett ikke hovedpoenget)

      Som en løsning på generell basis gir jeg støtte til en slags twitter-løsning: begrens anonyme IP-er til et visst antall kall per time. Hvis man trenger mer enn dette antallet kall må man registrere seg på en eller annen enkel måte og og få en nøkkel; da vet dere ihvertfall hvem som bruker masse trafikk, og kan kontakte dem 🙂

    • Web APIer bør alltid designes slik at det prinsippet du forfekter ligger i bunn for designet. Dette prinsippet kan vi kalle «Splitt og hersk». Jo raskere nettene blir, jo viktigere blir dette. Mange uerfarne utviklere mangler nødvendig forståelse for dynamikken mellom klient-nett-server, og med for kraftige APIer til rådighet står de i fare for å jamme backend serverne.

      I tillegg er det viktig at APIene leverer en sammensetning av data som er homogen mht foreldelsespolicy. Dette er viktige for å kunne sette presise headere for cacher. Jeg er usikker, men lurer på om XML varselet til yr.no kunne vært delt opp og levert på forskjellige REST endepunkt med forskjellige Expire/max-age headere.

    • Forslaget til Ove Andersen høres for meg (uten at jeg på noen måte er noen ekspert) spesielt tiltalende ut. Det er kanskje den minst dyptgripende endringen hva fri tilgjengelighet av dataene angår, og har kanskje også en fin bieffekt: De programmene som i dag ikke oppfører seg, kan vel tenkes å feile uelegant når de utsettes for rate-limiting — dette vil forhåpentligvis gi utviklerne av slik programvare et godt insentiv til å rette opp sine feil (klager fra brukerne, etc.).

      En slik myk løsning bør vel i hvertfall prøves ut før man går mer «drastisk» til verks med nøkler og tvungen registrering?

      En annen ting som slår meg, dersom rate-limiting-forslaget ikke er tilstrekkelig, er at en kanskje bør prioritere det viktigste, nemlig de faktiske værdataene. En kan for eksempel kreve registrering og nøkler for bruk av koordinat-til-sted-APIen, men la værdatene være tilgjengelig på samme måte som i dag. En av dere nevnte vel også at selve varsel.xml ikke er den store belastningen her, og det er jo disse dataene som er det aller viktigste Yr kan by på.

      Nok en løsning kunne være å gi opp koordinat-til-sted-tjenesten fullstendig, og tvinge folk til å gjøre dette selv. En kunne kanskje ved jevne mellomrom (årlig?) dumpe en flat fil med koordinatene til de stedene Yr varsler for. Denne kan beskyttes med innlogging/registrering (men være under en fri lisens), og så kan utviklerne distribuere den som en del av programvaren sin, og selv gjøre koordinat-til-sted-oppslaget på brukerens egen PC/telefon/dings.

    • David Karlsen (svar til Ove Andersen)

      Helt klart den beste løsningen – jeg vil tro at det er en liten andel av brukerne som står for den største belastningen.

  3. Ser dere peker på Android App’er som en av de store synderene.
    Jeg vil tippe at de fleste «nedlastingene» er fra Widgets, og ikke bakgrunns app’er, slik som denne: https://market.android.com/details?id=com.ermesjo.yrp

    Den erstatter ofte klokka på en av hjemmeskjermene og oppdateres automatisk, Hver 3., 6., 12. eller 24 time, og å si at de ikke vises er vel en overdrivelse, den vises «hver» gang telefonen er i bruk. – Android er ikke iPhone, og bruken er forskjellig 🙂

    Jeg tror det er bedre å lage retningslinjer for hvordan en klient kan oppføre seg, og ta kontakt med utviklere med app’er som bryter denne retningslinjen.

    Håndheving kan skje ved at utvikler selv generer en unik klient key – som sendes pr epost (for verifisering av kontaktinfo) og så kan utvikler automatisk varsles hvis klient bryter retningslinjer, og så etter en periode, hvis overtramp fortsetter, kan denne key sperres. – Dette vil «løse» Android problemet.

    Fyi : «Alle» HTC Android/WinMo telefoner har en widget som gjør dette, og som oppfører seg «likt» (geodata+tid=oppdatering), men da mot weather.com

    Men det viktigste er at det lages retningslinjer som kan håndheves – det at en «App» blir populær, bør jo ikke diskvalifisere den…

    Mine $0,2 🙂

    Svar på denne kommentaren

    • Det er stor skilnad på weather.com og yr.no: Weather.com har berre varsel for nokre få tusen stader i verda, medan yr.no har klinka til medvarsel for 8,3 mill. stader. Det lat/long-baserte api-et kan gje ut varsel for alle koordinatar i heile verda, ergo er dette langt mindre cache-bart enn weather.com.

      I Oslo har f.eks. weather.com berre eitt varsel, som eg vil gjette på at eigentleg er for Gardermoen.

    • Korrekt, det var ikke for å måle weather.com mot yr.no – men heller at dette er «forventet» funksjonalitet, som ønskes forbedret ved at yr.no brukes som datakilde

  4. Experimenter litt med stacken. CouchDB ,Memcached og en lett webserver.

    Å legge til ekstra nøkkler vi gi serverne mer å jobbe med per request. Og det er jo ikke gitt at det minker trafikken.

    Jobber med en løsning som skal gi ut mye data nå, men den er enda ikke oppe å kjører, så har ikke noen relle tal å vise til, men testene vi har gjort lover godt.

    Svar på denne kommentaren

  5. Ganske sikker på at artikkelen er skrevet med Norsk.

    Jeg tror en nøkkel og epost-registrering kan være en idé, og ha en automatisk advarsel sendt ut før nøkkelen blir sperret, slik at utvikleren kan enten varsle brukerene av appen/nettstedet at den kommer til å bli stengt, eller at de kan rette opp i måten den henter data på.

    Jeg tror jeg hadde blitt irritert om appen min plutselig hadde sluttet å funke, og jeg måtte feilsøkt en stund før jeg fant ut at det var nøkkelen som var sperret.

    Svar på denne kommentaren

    • Korleis tenkjer du at varslinga burde skjedd?

      Vi har eit konkret eksempel: For eit par mnd sidan var éin Android-applikasjon i ferd med å ta oss ned. Det tok over ei vekes arbeid med å få tak i mannen som hadde laga applikasjonen, og så tok det to veker før han hadde skjønt kva han gjorde feil og fekk sendt ut ein ny og korrigert applikasjon. I mellomtida vart servarane flooda med førespurnader.

    • Ole Martin Handeland (svar til Erik Bolstad)

      Dere kan ha et skjema der en registrerer seg for å få nøkkel, og med et frivillig epost-felt. Det kan gjerne spesifiseres at dersom ingen epost oppgis, vil nøkkelen kunne sperres uten varsling. De som oppgir epostadresse får da epost når (eller før) deres tilgang blir sperret.

  6. Jeg mistenker det kan være vanskelig å bli kvitt Android-segmentet da en forholdsvis stor andel kanskje ikke vet de laster ned disse dataene. Min erfaring er at mange smartphone-brukere har fått telefonen av arbeidsgiver, men verken er interessert i eller har kunnskap til å gjøre de konfigureringer som man bør når man får en slik telefon.

    Jeg synes også at data bør være åpent tilgjengelig uten for mye registrering. Både fordi utviklerne vil ha tilgang til data her og nå uten å gå om plagsom registrering, samtidig som Yr.no helst vil slippe administrasjonen som følger med. Men hva om man innfører en todelt modell?

    Kan man ha en åpen løsning for «uvitende» Android-brukere og andre anonyme uten nøkkel? Denne gir riktignok data, men kanskje redusert mengde etter Twitter-varianten.

    Samtidig kan man f.eks innfører et nøkkelsystem der man registrerer domene og/eller IP-adresse, hvor nøkkelen bare er gyldig i kombinasjon med domene/IP-adresse. Da unngår man problemet med at man låner hverandres nøkkel. Utfordringen da er å unngå at denne autentiseringsmekanismen krever for mye overhead og i seg selv blir et problem.

    For egentlig tror jeg ikke at lån av andres nøkler blir noe stort problem. De som er interessert og seriøse skaffer seg nok egne nøkler selv. Men om man klarer å skille mellom de «anonyme» brukerne som laster ned uten bevisst bruk, og de som har fått tildelt en nøkkel tror jeg kanskje mye vil være oppnådd.

    Lykke til!

    Svar på denne kommentaren

  7. Jeg er veldig interessert i bit-torrentløsningen som blant annet er i bruk i Spotify.
    Altså data (i spotifytilfellet; musikk) blir cachet på klientmaskinen og blir gjort tilgjegelig for andre klienter gjennom sentral server og API.

    Dette burde senke belastningen på serveren en god del.
    Spesilet hvis utviklere enkelt kan kjøre data inn på egen server så de slipper å teste mot Dere direkte hver gang.

    Svar på denne kommentaren

    • Sikander (svar til Gard)

      Det må nok undersøkes og testes nærmere, men informasjonsmengden er vel ikke så enorm per enhet at det burde være et stort problem?
      Og det er vel opp til hver enkelt programmerer å bestemme hvor ofte en enhet kan sende info videre?

      Jeg er ikke ekstremt bevandret med programmering, men jeg synes det er en ide som bør utforskes videre. Å spre informasjon på denne måten avlaster stort sett masternoden betraktelig. ihvertfall når det er ekstremt mange enheter som ber om tilgang til dette.

    • Thomas Nygreen (svar til Sikander)

      Bit-torrent fungerer kun effektivt dersom det også er andre som etterspør eksakt samme informasjon.

      Har forstått det sånn at i hvert fall en del av problemet her er forespørsler som gjelder varsler for spesifiserte koordinater. Siden disse varslene også har relativt kort levetid, er det vel lite sannsynlig at noen andre har etterspurt akkurat de samme dataene.

      Og så kommer jo driftinga av en torrent-tracker i tillegg.

  8. Anbefaler å se på hvordan feks Read It Later har valgt å gjøre det (http://readitlaterlist.com/api/signup/). Fyll ut app-navn og e-post og du får nøkkelen med en gang.

    Jeg tror de fleste utviklere har forståelse for at tjenesteleverandøren må kunne få tak i de ved feil bruk av API’et, men samtidig er det veldig greit om man slipper en endeløs registrering for å få tak i nøkkelen.

    Svar på denne kommentaren

  9. Sett opp cache tida, evt. automatisk utregning av cache tida.

    Sett på ein cache server slik at ofte brukte kall ikkje treffer databasen.

    Åpne for nedlasting av heile datasett f.x. http://static.yr.no/norge.xml.bz2

    Legg ut eksempelkode som ikkje laster ned for mykje data for utviklere å bruke. Her kan de sette ned nøyaktigheten i tid og plasering.

    Dersom dette ikkje hjelper set opp ein grense for antall forespørsler for kvar IP. Merk at mange brukere kan gjøyme seg bak samme IP så her må du ha ei god kviteliste.

    Ellers ser eg at det ikkje er lett å få værvarsel gitt koordinatar. Det er ikkje alle (særlig mobile enheter) som veit kva det heiter der dei er.

    Svar på denne kommentaren

    • Jeg hater å framstå som besserwisser her, men dette burde ikke hindre caching. Jeg antar at varslene kommer på relativt forutsigbare tidspunkt hver dag? Om dere hadde satt opp en cacheserver og latt app-serveren sette Cache-Control-headere til å expire på dette tidspunktet (eller fast til en time fram for den saks skyld) burde det gjøre bra greier for ytelsen.

    • Oppdateringane kjem på halvfaste tidspunkt, men varierer gjerne med ein time eller to… Mange av varsla blir etterkorrigert av meteorologar, og då er det nesten umogleg å gje nøyaktige tidspunkt for når varsla blir ferdige. Det er òg stor variasjon i når varsla er ferdige frå tungrekneanlegga.

    • Burde vel ikke spille så stor rolle når dataene oppdateres. En cache med levetid på noen minutter kan vi vel leve med uansett? Og så kan man invalidere cachen når nye data er tilgjengelig.

      Hovedproblemet er vel at det kommer så mange ulike requests.

      Jeg ville hørt med Akamai, de er veldig gode på caching av data.

    • Og fremdeles sier dere til cacheserverene deres at de bare skal huske dataene i 1 minutt? 🙂 Det skurrer jo litt? (Med mindre dere tvinger inn lengre caching til Varnish)

      Det er jo ingen grunn til å tvinge all cache til å bli utdatert på 1 minutt om ting bare oppdaterer seg 8 ganger i døgnet, som ikke er særlig ofte.

      Varnish støtter jo også muligheten for å automatisk slette cache ved endring av kildedata. Noe som kan bety at data blir cachet av Varnish for alltid inntil dere faktisk oppadterer dataene bak. Noe å vurdere?

  10. (Beklager dobbelpost, håper den forrige forsvinner). Forslaget til Ove Andersen høres for meg (uten at jeg på noen måte er noen ekspert) spesielt tiltalende ut. Det er kanskje den minst dyptgripende endringen hva fri tilgjengelighet av dataene angår, og har kanskje også en fin bieffekt: De programmene som i dag ikke oppfører seg, kan vel tenkes å feile uelegant når de utsettes for rate-limiting — dette vil forhåpentligvis gi utviklerne av slik programvare et godt insentiv til å rette opp sine feil (klager fra brukerne, etc.).

    En slik myk løsning bør vel i hvertfall prøves ut før man går mer “drastisk” til verks med nøkler og tvungen registrering?

    En annen ting som slår meg, dersom rate-limiting-forslaget ikke er tilstrekkelig, er at en kanskje bør prioritere det viktigste, nemlig de faktiske værdataene. En kan for eksempel kreve registrering og nøkler for bruk av koordinat-til-sted-APIen, men la værdatene være tilgjengelig på samme måte som i dag. En av dere nevnte vel også at selve varsel.xml ikke er den store belastningen her, og det er jo disse dataene som er det aller viktigste Yr kan by på.

    Nok en løsning kunne være å gi opp koordinat-til-sted-tjenesten fullstendig, og tvinge folk til å gjøre dette selv. En kunne kanskje ved jevne mellomrom (årlig?) dumpe en flat fil med koordinatene til de stedene Yr varsler for. Denne kan beskyttes med innlogging/registrering (men være under en fri lisens), og så kan utviklerne distribuere den som en del av programvaren sin, og selv gjøre koordinat-til-sted-oppslaget på brukerens egen PC/telefon/dings.

    Til slutt: Takk for en flott tjeneste! The Internet, you’re doing it right 🙂

    Svar på denne kommentaren

  11. Om det er posisjons-webservicene (lat/lng) som skaper mest trafikk kan det være mulig å senke oppløsningen på posisjonene til et maks antall desimaler på lat/lng, eksempelsvis at posisjonen snappes til nærmeste «kjente sted».

    Ev. kan registrerte tjenester med API-nøkkel få tilgang på høyoppløselige posisjoner.

    Svar på denne kommentaren

    • Det er akkurat dette vi fant ut var den mest effektive løsningen på RealRadios.com. Der har vi også caching av lat/long i stor stil – og vi gjør det nå primært på 3 desimalers oppløsning.

      Hvis man skal begynne å bruke API nøkler kunne man jo gi de med nøkkel full oppløsning – mens de uten nøkkel kjøres på 3-4 desimaler på lat/long… Da kan man sperre de som har skrevet elendig kode og bruke nøkkel, eller levere cachede resultater med redusert oppløsning…

    • Kan vi strippe vekk desimalene i Varnish? Eller er det andre Varnish triks som gjør at f.eks:

      1.30000022323
      1.30
      1.301

      Oppfattes som samme request og cachet innhold leveres ut?

    • Som bruker av tjenestene ser jeg ikke noe stort problem med en evnt API nøkkel løsning (ref kart så droppet Google det i v3 av API sitt) – og da kanskje særlig for de mer komplekse / eksotiske delene av tjenesten.

      En forenkling eller tydeliggjøring av deler av API kunne sikkert også vært greit, f.eks en visuell oversikt over forskeller i lat/long opp mot varsel – og da gjerne forenklet til få desimaler (en liste over vanlige relevante steder med kobling mot YR løsningen kunne kanskje også vært relevant for bedre ruting og bruk? Dvs oppslag GPS til «god nok» id som eget søk/API)

      Ville også tro at deler av varsel kunne brytes ut med ESI og ha lengre levetid (og da også være direkte tilgjengelig som kall? Kun i morgen, eller kun all vind styrke)

      MEN… Med nøkkel må info lyt og kontaktskjema på API.mrt.no bli mye bedre, jeg tror jeg fikk lagt meg inn som mottager tredje gang prøvde – men har ikke kommet mye info ut (nrkbeta er bra kanal for info og debatt, flytt API dok og eksempler også hit!!!)

  12. nå kan jeg ingenting om utvikling eller kode etc., så jeg skal først og fremst uttale meg om «åpenhetsprinsippet»:

    slik det ser ut fra deres beskrivelse (og kommentarene) så er det lettere å kontrollere kall fra en IP-adresse enn fra en mobilapp. dermed så er det vel selve appen – og dermed utviklerne – som er det springende punktet?

    jeg mener at en registrering fra utviklernes side, der de gir nok informasjon om seg selv til at dere får tak i dem kjapt om det skulle være nødvendig, bør være en overkommelig terskel for å drive mer eller mindre seriøs utvikling (og er du useriøs eller bare skal leke deg litt med dataene, så kan du jo bare legge igjen en john doe-adresse eller noe).

    I tillegg til registreringa så bør det ligge noen vilkår til apper, om antall kall per time (som foreslått over). Dette er heller ikke noen begrensning på «friheten» til dataene; kun en begrensning som sier at du ikke får lov å overbelaste systemet.

    men jeg tror det er viktig, om mulig, at mobilbrukerne ikke trenger å gjøre noen registrering. mulig dette kan gjøres på en sexy måte, men jeg tror likevel det er en showstopper som verken Yr eller utviklerne ønsker. (men det er kanskje ikke mulig å se hvilken app det er som sender spørring til databasen?)

    kort sagt; om utviklerne må holdes litt i øra (det må de), så må dere gjøre det – og tids-/ressursbruken må nødvendigvis i hovedsak utviklerne selv stå på; det være seg gjennom registrering, bedre gjennomtenkt kode (med hensyn til servernes faktiske kapasitet), eller en UI som gjør at en evt. registrering fra brukerens side blir så sexy og kjapp som mulig.

    Svar på denne kommentaren

    • Takk for gode innspel!

      Du har heilt rett: Problemet er ikkje kall frå enkelt-IP-adresser (desse er lette å sperre), men når f.eks. ein mobilapplikasjon (der alle brukarane har ulike IP-adresser) går bananas og lastar ned uhorvelege mengdar data.

      Vi ser absolutt ikkje for oss at sluttbrukarane må skaffe seg nøklar, det er berre utviklarane som lagar appar som eventuelt må gjere det.

      Vi er framleis veldig opne for innspel og gode idéar til korleis vi kan gjere dette enkelt og rimeleg.

    • Enig

      Synes det er mer en fair at utviklere bruker en key/nøkkel i sin app. Og så er det bare å gjøre prosessen med å få en nøkkel enkel og grei.

      Hvis utvikler legger igjen e-post adresse, så vil utvikler få varsel før evt. sperring.

      Hvis noen utviklere har problem med det, så skjønner jeg ingenting…får være måte på hvor kravstor man skal være når noen gir ut værdata som man kan bruke fritt i sine applikasjoner :O

      Alle som ikke bruker nøkler bør minimum ha en form for limit på antall kall pr time.

      Det er tross alt vesentlig viktigere for oss alle (både utviklere og brukere) at tjenesten er responsiv, enn at utviklere skal slippe å bruke 5 minutter på å fylle ut en webform for å få nøkkel 🙂

  13. Hva med OpenID for registrering? De fleste utviklere har vel det allerede (eller burde skaffe seg det), og da burde det være greit å bare dytte inn den og så få en nøkkel per webside eller app eller hva en nå måtte velge i den enden.

    Svar på denne kommentaren

  14. Er problemet at de fleste requests ikke er cachet, eller mengden requests?

    Altså at selv når dataene er cachet blir det for mye for serverne å takle. Isåfall vil jo ikke et nøkkelsystem gjøre store forskjellen, da blir det som nevnt mer arbeid for serverne.

    Vurdert å bruke redis som et mellomlager for data. Betraktlig raskere enn memcached og persistent: http://code.google.com/p/redis/

    Hva er selve api-et skrevet i?

    Svar på denne kommentaren

    • Det er talet på førespurnader (requests) som eigentleg er problemet, ikkje cache-tid eller cache-lag.

      Frontane på yr.no er laga i .Net og ein del andre teknologiar. API-et er Rest-basert og laga med ulike opne teknologiar.

  15. Espen Breivik

    Ser ingen problemer med å kreve nøkler med enkel registrering (evt. OpenID som foreslått). Når noen først har tatt utvikler-steget og greid å dra ned data, så greier de jammen å registrere seg også.

    Dette må jo være det beste kompromisset. Det å få tilgang til slik data gratis er jo fantastisk nok i seg selv.

    Svar på denne kommentaren

  16. Hva med at dere faktisk setter dere ned og lager en android-app som tilfredsstiller de kravene dere måtte ha til applikasjonen for at det ikke skal ta helt kverken på serverene dere har?

    Per dags dato finnes det ingen gode vær-apps på markede som ser pen ut med mindre man vil betale for det og når dere først vil publiserer denne applikasjonen så tør jeg vedde mye på at dere vil få mer kontroll på trafikk-dataen deres og dere vil forhindre at «Ola Nordmann» tilnærmet DDos’er dere.

    Svar på denne kommentaren

    • Thomas Nygreen (svar til b-real)

      Enig! Det hadde vært flott med en offisiell app. Mange ville nok også valgt den framfor apps fra utviklere de ikke vet hvem er.

      Tipper at utgiftene til å utvikle en offisiell yr-app fort spares inn i form av mindre hardware-innkjøp.

  17. Bart Simpson

    Ååå så populære dere er! 🙂
    Interessant problemstilling, men det er vanskelig å gi noen tips når jeg ikke fikk noe inntrykk av hvor skoen trykker. Er det båndbredde? Cpu? Spesielle databaseting?

    Kanskje dere kunne vurdere en forsinket respons for de største synderne, 10 sek, og la de få vite at om de begrenser seg litt, eller betaler?, så får de raskere respons.

    Svar på denne kommentaren

    • Tenkte på det samme, responstiden er gjerne ikke veldig kritisk. Det bør være mulig å ha en lettvekter av en server (nginx eller lignende) som kun køer forespørsler.

      Request-timeout blir da naturligvis problem om det blir ekstremt mange requests, men da lever hvertfall serverne fortsatt.

    • Vi kunne godt laga eit eller anna som gav forseinka respons til dei største syndarane, problemet er å vite kven dei er når førespurnadane kjem frå ulike IP-adresser.

  18. Hva med å bruke nettskyen til servering av data. Det skalerer godt og er billig sammenlignet med å ha egne IT grunts som drifter miljøet og egne servere.

    Siden det er åpne data så er det jo ikke noe sikkerhetshensyn å ta med tanke på at det lagres hos en tredjepart.

    Ser ikke hvorfor det ikke allerede er i nettskyen? Noen som har noen god grunn for at det ikke skal være det?

    Svar på denne kommentaren

  19. Jeg slår ett slag for egne dedikerte servere til de som registrerer seg eller vil betale for å ha fri tilgang.
    Disse bør da ha tilgang på ett kluster av servere som kan levere til massen som bruker tjenesten.

    Så kan man ha ett API som bruker REST og limiting.

    Og forhåpentligvis kan man ha fri tilgang via normal browsing med nettleseren sin 🙂

    Svar på denne kommentaren

  20. […] NRKbeta skriver om trafikken mot yr.no som i utgangspunktet er veldig høy, men som i de siste månedene har økt kraftig. Dette skyldes ifølge loggene deres hopvedsaklig to ting: 1. Test-sider som sjekker unødvendig mye og ofte xml-data fra yr.no. 2. Android-applikasjoner som laster ned data fra yr.no særdeles mye. Det er mye nedlastinger som ikke blir sett. Spesielt gjelder dette for punkt nummer 1. […]

    Svar på denne kommentaren

  21. Lag en eksplisitt cache som oppdateres ved endring i kilden – da treffes backend kun en gang per sted. Legg så en bedre tilpasset web cache oppå. Bruk e-tags og cache-control headere i http-protokollen.

    Sist men ikke minst – når løsningen skalerer horisontalt kan dere putte det i nettskyen, f.eks Amazon s3

    Svar på denne kommentaren

  22. Som mange andre har foreslått: Bruk Varnish til dette. Sett opp Varnish til å cache alle koordinat-svar. Varnish støtter cache-channels som passer fint for dere som invalideringsmetode for frontend-cache laget. I tillegg kan dere f.eks serve gzip’ede data for å få ned båndbreddeforbruket. Varnish vil cache ferdig komprimerte filer og serve det uten problemer.

    F.eks Varnish Software eller Redpill Linpro kan helt sikkert hjelpe dere her. Disse selskapene har erfaring med slike problemstillinger.

    Svar på denne kommentaren

    • Poenget er ikke å bare bruke produktet, men å bruke mulighetene det gir det på en riktig måte.

      Dette problemet er ikke større enn at du kan holde det aktive datasettet i RAM. Du kan ha flere lag med cacher og invalidere objekter gradvis når nye data er på plass for å ikke drukne app-serverene dine.

      Greier du ikke å løse det selv, så søk hjelp fra folk som har løst slike problemer før. Store datasett og mange forespørsler er ikke et spesielt unikt problem.

  23. Disclaimer: Jeg jobber for Varnish Software.

    Først og fremst. Tusen hjertelig takk for en strålende tjeneste.

    Til saken. Dagen servere er usannsynlig kraftige saker. Jeg tror min laptop greier å kjøre rundt 100 millioner linjer C per sekund, så lenge jeg ikke gjør noe som involverer operativsystemet. Dette er vannvittig mye.

    Dere ligger vel på rundt 20-40 requests per sekund. Hovedproblemet ligger i å matche lat/long med varselsted. Jeg vil tro, at så lenge dere greier å tvinge datasettet deres inn i minnet så burde en enkelt server fint greie å koble lat/long med varsel-sted. Og 8.2M varselsteder er ikke så skrekkelig mye i forhold til hva en server kan holde i minnet.

    Hvis dere «pinner» data i minne. Sørg for at alt skje i en applikasjon slik at operativsystemet blir involvert når komponentene skal prate sammen. Det krever dog et par tusen linje med C-kode og er særdeles uegnet for kompleks foretninglogikk.

    Fase to – å levere selve XML-dokumentet som inneholder det faktiske varselet, burde være en smal sak. Selv om du leverer hver eneste request fra roterende disker så burde en eller to servere greie å levere.

    Svar på denne kommentaren

    • Trond M. (svar til Arne)

      yr.no/sted/…/varsel.xml henter data fra api.met.no. api.met.no cacher data med varnish, og yr.no cacher også resultatet i noen minutter.

      Varnishserverene våre har det egentlig relativt bra, og så lenge requestene treffer cachen, så spytter varnish ut sidene uten problemer. Men, siden vi ikke vil ha gamle varsel i xml-dataene, så tømmes cachen hver time, i tillegg til de de 4-8 gangene i døgnet som selve varselet oppdateres. Hver time vil det da komme en storm med requester til backenden, og jo flere unike URLer som kommer på en gang, jo større problemer får vi. Da er det spesielt problematisk hvis alle de forskjellige mobilapplikasjonene bittelitt forskjellige URLer for det som i utgangspunktet vil gi det samme varselet.

      Jeg tror mye vil være gjort ved å normalisere URLene, slik at lat=60;lon=10 er det samme som lon=10;lat=60 og lon=10.0;lat=60.0 og lat=60%2e0;lon=10%2e0 osv.

      Det kunne også vært interessant å se om det ville latt seg gjøre å bruke ESI eller en eller annen annen mekanisme til å la varnish invalidere de delene av XMLen som går ut på tid, uten å invalidere hele xml-objektet. Da bør vi spare 24 cache-tømminger i døgnet og objektene vil kunne leve veldig lenge av gangen.

    • Thomas Nygreen (svar til Trond M.)

      Hva med å sørge for at ikke alle varsel.xml invalideres samtidig? Enten kan dataene som serves til cachen når varslene nettopp er oppdatert ha en random expire på mellom 1 og 60 minutter, eller så kan dere ha en enkel tjeneste som rusler over og invaliderer én og én varsel.xml, i løpet av den første timen etter en oppdatering. Da får dere spredt loaden utover hele timen.

      Støtter også det flere har skrevet her om at det er veldig mye informasjon i varsel.xml. Men det er kanskje ikke ønskelig å endre i den funksjonaliteten dette gir, og om dere skal serve en lett-versjon i tillegg blir det jo også mer å holde styr på. Det løser heller ikke problemet med antall requests, men reduserer datamengden.

  24. Sebastian Steinmann

    Du sier at det ikke er cache som er problemet, dataene er cachet og dere bruker ikke ekstremt mye tid på dette.

    Løsningen slik jeg ser det kan være dns-basert lastbalansering. Sett opp 2 eller flere frontservere og ha round-robin dns.

    Virker virkelig ikke som at api-nøkkel er løsningen når mengden forespørsler er problemet. Det blir nok like mange forespørsler, men dere trenger ekstra kall for å sjekke de.

    Svar på denne kommentaren

    • Det vi ønsker å oppnå med en api-nøkkel er hovedsaklig å identifisere applikasjoner som skaper problemer, slik at vi enkelt kan kontakte utvikler og be dem komme med en fiks kjapt og eventuelt avvise requester fra den aktuelle applikasjonen.

    • Men man har jo egentlig ikke noen garanti da heller, vel? Hvis et program er under en fri lisens, kan jo ikke den opprinnelige utvikleren, som dere har kontaktinformasjon til, gjøre noe med de potensielt ørten forks som fortsetter å bruke samme nøkkel.

  25. Sjur Ringheim Lid

    Dersom dere innfører registrering bør dette helst gi mere tilbake til brukeren. Å gi brukeren egne subdomener eller bruks statistikk basert på nøkler kan være noe som vil gi utviklere en grunn til å ønske å registrere seg, men det bør kombineres med den helt frie uregisterte bruken dere har i dag.

    Svar på denne kommentaren

  26. Kjetil Kjernsmo

    Leit at dette skal være et problem!

    Jeg vet ikke helt hvor mye det kan bety, men HTTP har faktisk en From-header som er ment å settes til mailadressen til den som kontrollerer agenten:
    http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.22

    I gamle dager, hvis man lagde noe som skulle hente mye data ble det sagt at From-headeren alltid skulle settes. Perl-modulen LWP::RobotUA krever det den dag i dag…

    Brukne apper er det kanskje ikke så mye å gjøre med, men det kan kanskje være sånn at hvis man detekterer mange nedlastninger, så avvises requesten med feil 400 hvis den ikke inneholder en From-header. Så kan man logge From-headerne, og sende en mail automatisk hvis ting går stokk over stein. Eventuelt kan man da også ha en svarteliste med adresser som er bouncer eller ikke klarer å oppføre seg over tid.

    Det er vanskelig å si om dette vil hjelpe på å få ned trafikken, men det er mulig det vil være tilstrekkelig. Her bruker man en HTTP-mekanisme helt og holdent, og det er derfor et mindre steg enn å kreve registrering.

    Svar på denne kommentaren

  27. Det er leit å se at dere gir dette en negativ spinn. I bunn og grunn er det APIet og datagrunnlaget her som er problemet, ikke det at folk faktisk bruker tjenesten. Om brukerne blir tvunget til å sende mange forespørsler for å få ut den informasjonen de trenger så burde man gå igjennom logger for å finne mønster, som igjen forteller noe om hvilke API-funksjoner som mangler.

    Alle forslagene om API-nøkkler or throttling er forsåvidt gode, men ingen gylden løsning som vil fjerne alle problemer. Det store problemet med API-nøkkler er gjenbruk; Ofte ender man opp med å se at samme nøkkel blir brukt flere steder fordi utviklere ofte stjeler/blir inspirert av andre sin kode. Begrensninger til subdomener ol. slutter å være nyttig når man gir ut API-nøkler som brukes i applikasjoner.

    Kan man få se mer detaljer om hvordan løsningen er bygd opp, og hva slags hardware som er dedikert til denne tjenesten?

    Svar på denne kommentaren

    • Dette er kloke tankar!

      Eg trur ikkje at vi skal prøve på å leggje ut skisser over alle dei ulike laga med servarar og informasjon.
      Vi har heilt klårt eit effektiviserings- og forbetringspotensiale i koden, både her i NRK og på Meteorologisk.

      Poenget er vel eigentleg at ein kan optimalisere kode og servarstruktur i det uendelege, men kva i all verda gjer vi om alle utviklarar som forstår engelsk byrjar leike med dataene? Då går det lukt åt skogen.

      Vi skal klare oss ganske lenge til utan for drastiske tiltak, men ynskjer å starte arbeidet med å lage eit betre system; og då lurte vi på om nøklane var ein god idé.

  28. Tokk en titt på xml som faktisk blir servert og problemet må være at 90% av informasjonen dere sender faktisk ikke brukes.

    Jeg er sikker på at disse mobilapplikasjonene kun vil ha været i dette sekund og kommer derfor til å kjøre en ny request innen neste periode, så kanskje ha en egen request for «langtidsvarsel»?

    Antar at long/lat data blir cached i memcached, og trenger vel aldri å bli invalidert?

    Jeg ville kjørt noen tester å sett hvor mye dere sparer på å bare hente ut værdetaljer for en periode istedenfor hele uken.

    Kjedelig å endre et api som er i bruk naturligvis.

    Deres backend trenger strengt tatt ikke alle bjellene og trompetene .net har med seg, hadde derfor kanskje vært en idè og sette opp et superenkelt backend som kun jobbet med data.

    C er kanskje litt drøyt å starte med, men kommer langt med Java, bare ikke kjøre på med rammeverk etc.

    Svar på denne kommentaren

  29. Hei.

    Jeg savner en todelt service slik at ikke en del viktige tjenester ikke får tilgang på værdata pga stor pågang fra f.eks private. Vi vurderer nå å benytte grensesnitt mot yr for å hente værdata for et nytt prosjekt til en stor kunde. Dette prosjektet baserer mye av logikken sin på værdata. Kan man få en profesjonell tilgang med en SLA hadde det vært det beste i tillegg til en tjeneste som er åpen for alle.

    /Tomas

    Svar på denne kommentaren

  30. Hi!

    I use the xml-files on few of my php-based sites, ex. svensktvader.se, ukkostutkat.fi. Few toughts on this bombing issue…
    I’m using Nginx as frontend of Apache what also cache the data for x seconds.
    Require users to cache the xml’s for say 3600 seconds like i do = restrict requesting same url twice from same ip/domain if website during that time.
    Dump coord to city-requesting, force users to use geonames.org databases and similar ways for that, it gives enough of forecasts. Its up to user to find the correct xml-file and not your problem as deliver of the data. Have just myself set up an own mysql-database using geonames and its easy to do.

    Keep up the great work yr.no!

    Svar på denne kommentaren

  31. Kanskje paradoksalt å føreslå noko som ville auka datamengda (potensielt), men eit program ville gjeve programutviklarane kontroll med kor mykje informasjon som vert gjeve brukarane.

    Slik kunne de som tilbydarar framleis gjeva eit godt tilbod, samstundes som brukarane sannsynlegvis ikkje vil merka stor skilnad i bruksoppleving, ettersom ikkje all data er naudsynt for dei.

    Behovet for ei slik teneste er der jo, og folk vil ønskja å nytta det beste blant alternativa. Men det er jo forståeleg om de meiner at dette er utanfor mandatet og oppgåvene dykkar.

    Svar på denne kommentaren

  32. Hva med følgende.
    1. En knippe statiske sider til testing som varnish eller noe lignende kan lettere ta unna.

    2. Åpen tilgang til de 10-20% hyppigst bruker koordinatene innen for en radius

    3. full tilgang med nøkkel

    Svar på denne kommentaren

  33. Bjørn Tennøe

    Har ikke Guardian ordnet dette greit på sin Open Platform»? Da jeg pratet med dem for en stund siden tror jeg folk fikk 5000 gratis-kall per dag (usikker på om det er per bruker eller per tjeneste). Etter det måtte man inngå avtale med Guardian (har ikke peiling på vilkår). Vet heller ikke om de krever registrering av tjeneste/utvikler, men siden de har vært i gang en stund har de sikkert mye erfaring å dele.

    Noe av det tøffeste med Guardian Open Platform er at grunnleggerne også var med å starte MySociety.

    Svar på denne kommentaren

  34. «Throttling» kan være en effektiv metode, dvs senke hastigheten til en som laster ned store datamengder, på en slik måte at det går saktere og saktere.

    Problemet er at applikasjoner/brukere kan tro at dette skyldes en feil, om de ikke skjønner at det er «by design». Samme metode er blitt brukt mot virus men p.t. ikke en særlig populær metode fordi man lett kan tro at man har en treg server, hvis den begynte å «throttle» av feil grunn – dvs lovlig nedlasting.

    Svar på denne kommentaren

  35. Rate limit høres fornuftig ut mot de som f.eks ikke har registrert seg. De som er registrert har dere jo da kontroll på og kan kontakte dem hvis det viser seg at App’ene dems har feil.

    Dere sier ikke så mye om hvor i serverparken dere merker belastningen, men siden dere sier at Varnish fungerer bra for dere, så kan det virke som at det er lengre nede dere ser belastningen f.eks på database laget, når cachen må oppdateres med nye data.

    Hvis dette er tilfellet så kan dere jo da velge å enten redusere datagrunnlaget (er det viktig å publisere alle 8,3 mill steder f.eks?), eller så gjør dataene raskere tilgjengelig 🙂
    Minne er billig i dag, SSD’er er gode alternativer. Ta f.eks en titt på FusionIO sine produkter. Legg hele basen i minnet, FusionIO produktene er raske og du får de opp til 5 TB og med 6GB/s båndbredde.

    De koster såklart litt, men hoster dere egen serverpark i dag, så har dere sikkert råd til ekstra minne/SSD/flash drives 🙂

    Svar på denne kommentaren

  36. Dette burde være enkelt.

    Krev helt enkelt handshake. Alle enheter har unike hardware-id eller IP.
    Ved første gangs kontakt med yr.no lagres handshake-id. Gitt av fra yr.no med et random nummer på X antall tegn basert på hardware id.

    Ingen hardware-id/IP = ingen data.

    5 minutter mellom hver oppdatering til hver handshake-id.

    Problem løst.

    Svar på denne kommentaren

  37. Først av alt, TAKK for at dere gidder å ta tak i problemet på en fornutfig måte istedet for å bare stenge ned og si «nei det har vi forsøkt og det gikk ikke».

    Her er mine tanker rundt dette:

    1. Innfør et ID/nøkkelsystem. Ikke noe kryptografisk kompliserte greier, bare nok til å identifisere en applikasjon. Anbefal utviklere å benytte en separat nøkkel per applikasjon/versjon/bruksområde; en registrert utvikler bør altså sitte med en «farm» av nøkler.

    2. Tilby et webgrensesnitt der utvikler selv kan se status for blokkering og eventuelt selv blokkere en av sine nøkler for å tvinge brukere til å oppgradere f.eks. ved feil. Statistikk per nøkkel vil bidra til å avdekke problemer og vil være et insentiv for å bruke separate nøkler istedet for å «låne».

    3. API’et bør fremdeles tillate forespørsler uten slike nøkler, men da med fornuftig rate limiting.

    4. Se på selve API-funksjonene. Identifiser hvorfor noen utviklere ser det formålstjenlig å teppebombe med spørringer; kanskje de egentlig trenger/ønsker dataene på en litt annen måte.

    5. Send ut info til registrerte utviklere om endringer i API’et, nyttige tips og «best practice».

    Svar på denne kommentaren

  38. Peter Jojansson

    Hei YR,

    Først: Nyttig tjeneste og kjempe initiativ. Takk for det!

    Tenker at jeres skrækk senarie er en halv mill. apps der spør hvergang klokken runder hel eller halv. Hvis vi tar for gitt at klokkene på telefonene svinger med opp til 5 min, vil det i en fin og teoretisk 1 sekunds verden være 17 tusen åpne sokler i de 5 minittene. Det kræver mye jern å betjene slike mengder snakk.

    Forstår jeg dere rett, er det mengden af innkomne «rå» forespørsler som gir dere hodebry. Mange av appsene på mobil er designet til å klare utfall. dvs at hvis de misser et dns oppslag på grunn af signalutfall venter de som regel litt og prøver igen. Dette kan dere kanskje dra nytte av ved rett og slett å «droppe» tilfeldige mobil kall i de kritiske minuttene. (Close eller Redirect til ugyldig adresse)
    Tenker at dere kan sjekke mot mobile ip adresse-puljer helt ute i load balance.

    Svar på denne kommentaren

  39. Ang. Cache regler og oppdateringer.

    Hvorfor kan ikke API’en levere data som er opptil 30min på etterskudd?

    At selve hjemmesidene osv. har data som er oppdatert realtime er OK, men om API’en leverer data som kan være 30min forsinket er vel ikke et problem.

    Hvis en applikasjon trenger å få data oftere oppdatert så kan det f.eks gjøres avtaler og en nøkkel kan benyttes.

    Utover dette så kan mye gjøres ved bruk av f.eks memcache og f.eks egne cache servere.

    Basert på de tallene dere har så burde dette la seg gjennomføre med 3-4 servere.

    Største synderen er nok altfor mange IO kall på disk som burde flyttes over til minne.

    Takk for en god tjeneste, håper dere kan fortsette å levere den!

    Svar på denne kommentaren

  40. Veeeeeeeeldig sent med forslag på en sak jeg allerede har svart på en gang, men jeg har kommet over noe nytt og veldig spennende som kan være aktuelt å utforske nærmere for teknologibevisste nrkbeta (jeg antar at dere får opp denne kommentaren i dashboardet deres, så da bruker jeg bare denne saken som et eksempel på hvor denne teknologien kan passe)

    ipfs er en relativt ny protokoll som bruker prinsipper fra blant annet blockchain og bittorrent til å levere web-innhold over et distribuert nettverk.
    en veldig god gjennomgang kan dere finne her: https://www.youtube.com/watch?v=JhE_J1-BKJE
    dette er en protokoll som tilsynelatende lett kan bakes inn i nesten hva som helst, og det hadde vært veldig interessant hvis nrk var interessert i å levere data ut til massene over dette. (så kan foreksempel utviklere av værvaslingsapper bruke det til å hente ned data fra ipfs-nettverket i steden for at alt går gjennom nrk sine servere).

    håper dette er et lite frø som kan bli til noe stort og vakkert… hvis ikke så kan ingen si at jeg ikke prøvde ihvertfall 😉

    Svar på denne kommentaren

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *. Les vår personvernserklæring for informasjon om hvilke data vi lagrer om deg som kommenterer.