allan ebdrup bloghoved ny

300 webservicekald og 1200 DB-kald pr sekund for 600kr om måneden

Jeg har bygget en service, der lader folk logge JavaScript-fejl i produktion. Den får en del trafik.

Den har været oppe og håndtere 300 webservicekald og 1200 database-operationer per sekund, uden at have problemer. Det hele kører på hardware i skyen, der tilsammen koster 600 kr om måneden.

Webservice-kaldene kommer hver gang en brugers website logger en JavaScript fejl, der er opstået for et af websitets brugere.

Med de ca. 500 websites der bruger servicen, nogle af dem med mange sidevisninger, bliver det nogle gange til over 300 JavaScript-fejl logget i sekundet.

Hver enkelt JavaScript-fejl, der bliver logget, kører igennem en forholdsvis avanceret analyse. Analysen indebærer at normalisere fejlen, slå op i allerede loggede fejl, gruppere fejlen korrekt hvis den er sket før og opdatere diverse aggregerede data, grafer og rapporter.
Et typisk webservicekald laver 1-2 database-opslag og 4-5 database-opdateringer. Så det bliver op til 1200 database-operationer per sekund.

Mit setup består af 3 stk. webservere (webdynos) hos Heroku, med Node.js. Første webserver er gratis og de to sidste koster $36 pr måned.

Databasen er MongoDB og ligger hos MongoHQ. Da den holder sig på ca. ½-1GB koster den ca. $25 pr måned inklusiv automatisk backup til Amazon S3.

Konkrete erfaringer

Systemet klarer trafikken uden problemer, nøglen til dette har været:

  • Jeg profilerer databasen og sikrer mig, at de databaseoperationer jeg laver, er optimeret og har de rette indeks.
  • Jeg udnytter den skemaløse natur af MongoDB, når jeg aggregerer data, ved bare at indsætte de attributter i dokumentet, som jeg nu har brug for.
  • Når jeg opdaterer tællere og aggregerer data bruger jeg ”safe:false” i produktion. Det vil sige, at opdateringerne kører som ”fire and forget”. Koden på webserveren får altså intet at vide, hvis opdateringen går galt. Webserveren skal ikke vente på at få svar tilbage fra databasen og databasen skal ikke sende et svar. Fejl dukker op i databaseloggen i stedet. Dette kan jeg tillade mig, fordi det ikke er verdens undergang, hvis nogle tællere og grafer ikke er 100% korrekte.
  • På grund af aggregering vokser det aktive dataset i databasen ikke ret meget. Det vil sige, at det kan være i hukommelsen på Mongo-databasen, der derfor ikke er begrænset af disksystemets I/O-hastighed.

Alt i alt er det et sjovt projekt. Jeg synes selv, det er ret utroligt, hvor langt man kan nå for næsten ingen penge. Hvis der skal skaleres yderligere, ved jeg at webserver antallet kan skaleres på under et minut og databasen indenfor en times tid.

Spørgsmål? Egne skalerings-erfaringer du vil dele?

Kommentarer (17)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Allan Ebdrup Blogger

Jeg har fået følgende spørgsmål på Google+

Giver det ikke latency-problemer at have webserver og db-server hos to forskellige udbydere?

Hvortil svaret er, at det ikke er et problem, fordi Heroku og MongoHQ som udgangspunkt benytter samme Amazon datacenter. Det to firmaer samarbejder også.

  • 2
  • 0
Carsten Hansen

Jeg håber ikke, at Heroku og MongoHQ læser dette, så sætter de nok bare prisen op medmindre de vil bruge det til markedsføring.

Alternativt, så må du aktivt opsøge dine kunder med flest hits. Der skal nok rettes i koden et par steder.

Jeg hørte engang fra en tidl. Microsoft ansat, at deres server, der tog mod blue-screen-of-death simpelhen gik ned pga. overbelastning, da den blev startet op. Der var nogle bestemte grafikkortproducenter, der skulle have et kursus og der stod mange servere og rebootede konstant.

  • 0
  • 0
Allan Ebdrup Blogger

Hvad kan systemet maksimalt håndtere, hvor mange kald/sek?


Den grænse har jeg ikke afprøvet. Og det afhænger også en del af hvad det er for nogle fejl der logges, da de giver forskellig belastning.
Mht. MongoDB, så har MongoHQ et dashboard, hvor jeg kan se Locked percentage. Når den når over 100% så er du i alvorlige problemer, du skal nok sørge for mere kapacitet noget før den ligger på 50%.
Der har jeg ikke været oppe. Men jeg ved at hvis jeg nærmer mig, så er det bare at maile eller skype til MongoHQ og så migrerer de databasen til en større, og dyrere, plan med mere kapacitet. Og hvis det bliver nødvendigt kan databasen nemt shardes (partitioneres).

  • 0
  • 0
Allan Ebdrup Blogger

Alternativt, så må du aktivt opsøge dine kunder med flest hits. Der skal nok rettes i koden et par steder.


Ja, det har jeg også gjort. Der var fx et enkelt stort website der loggede ca 200 fejl i sekundet, ham tog jeg fat i. De tog logning af, og ud fra de info de allerede havde i loggen, rettede de fejl og fik logning på igen.

  • 0
  • 0
Jesper Louis Andersen

Mange logningsservices, Riemann f.eks., kan lave "rollup" af den slags, så kun det første request af en bestemt type logges og resten bare tælles sammen. Du kan komme langt med en simhash der finder similariteten i logbeskeden og så laver en gruppering af lignende beskeder. I koden holder du så en hashtable over de forekomster du har så du kun logger dem en gang. Når du evicter fra hashtabellen grundet alder, så gemmer du count i databasen, så du har styr på hvor ofte den givne besked forekommer. Men dit system er så ikke længere fuldstændigt stateless og det er ikke sikkert det er dit ønske.

En mere avanceret løsning laver dendogrammer over backtraces med en similaritetsmetrik af en eller anden art. Det rodede jeg med en del da jeg havde titusinder af fejl i minuttet og skulle klassificere dem efter hvem der var ens.

  • 1
  • 0
Markus Hens

Fordi Allan har lavet en service, der kører uden specielle valideringer, transaktionssikkerhed, brugerauthentificering, krypterede og signerede webservicekald eller en masse integrationer til andre systemer.
Du kan fx ikke bare køre "fire and forget" på DMR, fordi det er alligevel interessant at vide om bilen nu rent faktisk er registreret eller ej ;-) Og det er også rart, at SKAT beskytter den service med alle mulige authentificeringer, autorisationer, firewalls, DMZ'er etc. - ikke at nogen stjæler din bil den vej igennem ...

  • 1
  • 1
Allan Ebdrup Blogger

Fordi Allan har lavet en service, der kører uden specielle valideringer, transaktionssikkerhed, brugerauthentificering, krypterede og signerede webservicekald eller en masse integrationer til andre systemer.


Der er masse validering, der er også en del transaktionssikkerhed (det performede også ret pænt inden jeg lavede fire and forget safe:true). Der er authentificering af at din log findes (404 hvis ikke). Hvis dit website kører https sendes logbeskederne over krypteret https. Men det er rigtigt at der ikke er nogen integrationer at tale om.

Essensen af det du skriver er dog korrekt, at min service er meget simplere end motorregisteret.

Men hvis det er rigtigt at man ikke kan håndtere 7000 transaktioner om dagen i motorregisteret så synes jeg faktisk også at det er temmeligt mærkeligt.

  • 2
  • 0
Allan Ebdrup Blogger

Mange logningsservices, Riemann f.eks., kan lave "rollup" af den slags, så kun det første request af en bestemt type logges og resten bare tælles sammen. Du kan komme langt med en simhash der finder similariteten i logbeskeden og så laver en gruppering af lignende beskeder. I koden holder du så en hashtable over de forekomster du har så du kun logger dem en gang. Når du evicter fra hashtabellen grundet alder, så gemmer du count i databasen, så du har styr på hvor ofte den givne besked forekommer. Men dit system er så ikke længere fuldstændigt stateless og det er ikke sikkert det er dit ønske.


Tak for pointers. Jeg bruger faktisk en simhash i nogle tilfælde, hvor det er oplagt.

Den her gruppering kompliceres af faktorer som at alle de forskellige browsere logger meget forskellige fejlbeskeder for de samme fejl. (Det er ret ufatteligt hvor mange forskellige browsere der rent faktisk findes)

IE er helt slem, for den logger JavaScript-fejl med fejlbeskeder der er lokaliseret til den lokale IE-installations sprog. Jeg oversætter faktisk en del af disse fejlbeskeder fra andre sprog til engelsk.

Alt i alt har grupperingen været det mest komplekse ved at bygge denne service. Det har først været mulig at forbedre den, da jeg havde de første par millioner fejl logget. Den er bygget udfra hvad der rent faktisk bliver logget. Men jeg vil da kigge på at optimere den løbende.

At flushe counters kan muligvis godt komme på tale. Men jeg kan ikke vente for længe, for brugeren forventer hurtig feedback når der opstår fejl.

  • 0
  • 0
Theis Borg

Tak for et super indlæg. Det er sjovt at høre hvad andre har af trafik og hvad det koster.

Mit hobbyprojekt kører på google appengine. Til at starte med var det gratis og derefter meget billigt, men nu er priserne sat mærkbart op.

Jeg har ca. 75-100 hits i sekundet. Prisen er $25-$30 om dagen hvilket jeg syntes er lidt dyrt (men hobbies skal jo koste penge ;-).

Prisen fordeler sig ca. på:
CPU: $10
DB: $10

og resten går til mails, channels, storage, osv.

  • 1
  • 0
Theis Borg

http://www.androidlost.com

Google Appengine sørger selv for skaleringen (lige nu har jeg 6-10 instances kørende) og alt spiller fint - men det koster så også en del.

Så jeg går lidt og leger med tanken om at prøve en mongodb, meeen jeg skal lige ind i teknologien først. Det er lidt af et spring når man er vant til en SQL syntaks :-)

Jeg havde egentligt planer om at købe en dedicated server med 16GB RAM hos Hetzner.com (http://www.hetzner.de/en/hosting/produkte_rootserver/ex4) men nu tror jeg lige at jeg prøver med MongoHQ til at starte med.

  • 0
  • 0
Allan Ebdrup Blogger

Jeg havde egentligt planer om at købe en dedicated server med 16GB RAM hos Hetzner.com (http://www.hetzner.de/en/hosting/produkte_rootserver/ex4) men nu tror jeg lige at jeg prøver med MongoHQ til at starte med.

Ja MongoHQ har en gratis prøve-version, der faktisk er rimelig vild, og Heroku har også en gratis server.

Der er også MongoLab.

og den nye ObjectRocket, der har været påstande om at deres performance er meget bedre end de andres fordi de bruger dedikeret hardware. RackSpace har valgt ObjectRocket til deres MongoDB-as-a-service provider til RackSpace kunder - så noget må de gøre rigtigt.

  • 0
  • 0
Log ind eller Opret konto for at kommentere