Poul-Henning Kamp: Ungdommen kan ikke programmere til et moderne OS

Den lynhurtige webcache Varnish blev udviklet for at demonstrere, hvor effektivt en moderne operativsystemkerne kan bruges. Det lærer man stadig ikke på udvikler-uddannelser, lyder det fra Poul-Henning Kamp, der står bag Varnish.

Mange af verdens tungest belastede websider aflaster serverparken massivt ved at bruge webcachen Varnish, der er open source og gratis at bruge - blandt andet Facebook og Twitter, foruden et væld af netaviser. Og grunden er den simple, at Varnish er lynende hurtig til at servere indhold til de besøgende, uden at de bagvedliggende servere skal trækkes med for mange operationer.

»I syntetiske benchmarks har Varnish leveret 175.000 requests i sekundet fra én enkelt maskine. Den leverer op imod én gigabit pr. sekund pr. maskine,« forklarer den selvstændige udvikler Poul-Henning Kamp, som i 2006 udviklede Varnish for det norske firma Redpill-Linpro med penge fra netavisen VG.no.

Men i første omgang var han ikke meget for ideen.

»Jeg var ikke vild med opgaven. Webservere var ikke min kernekompetence, men så gik det op for mig, at der lå en interessant opgave i det, nemlig at vise, hvordan man bruger en operativsystemkerne rigtigt,« forklarer Poul-Henning Kamp.

Han har i mange år arbejdet med FreeBSD-kernen og kender alle krinkelkroge og tricks til at få mest mulig ydelse. Men mange udviklere bruger ikke mulighederne særligt godt, var hans erfaring. Varnish kunne blive et stykke software, som kunne demonstrere, hvilke performance-forbedringer, der kan opnås med den rigtige tankegang.

» Jeg har siddet og kigget på undersiden af det her i årevis. Nu er jeg så kravlet op på oversiden. Det er derfor, jeg ved, at der er de faciliteter, og ved hvad de kan. Jeg oplever ret tit, at folk klager over performance i FreeBSD, men det viser sig, at de gør noget tåbeligt. Varnish var en god lejlighed til at vise, hvad man kan med en moderne kerne. Folk har ikke en disse forståelse for multithreading og virtuel hukommelse,« lyder begrundelsen.

For mange slås mod OS-kernen

Alt for mange ignorerer den hjælp, man får fra moderne operativsystemer, og så er der lagt op til ballade, mener han.

»Operativsystem-kernen giver dig jo en virtuel maskine til din proces. Og hvis folk ikke programmerer mod den virtuelle maskines performance-karateristiska, men mod den rå maskines karaktaristika, så går det jo galt, for så er de oppe og slås mod operativsystem-kernen,« siger freelanceudvikleren.

I stedet skal man indstille sig på, at operativsystemkernen klarer en del af opgaverne selv nu til dags.

»Med Varnish forsøgte jeg at programmere op imod den moderne abstraktion af en computer, hvor du har flere kerner, virtuel hukommelse og alle mulige kerne-faciliteter til at gøre det smartere. Men uanset hvor jeg holder mit foredrag om performance i Varnish, kan jeg se, at folk aldrig har hørt om den slags på deres uddannelse,« siger Poul-Henning Kamp

Når for eksempel virtuel hukommelse har været på banen i 40 år, er det ved at være en kende pinligt, at selv nyuddannede programmører ikke har lært at bruge det, mener han.

»Et klassisk eksempel er, at man står og flytter ting mellem disk og hukommelse hele tiden. Men det gør operativsystemkernen jo selv. Man skal bare lægge det et sted i den virtuelle hukommelse, så gør den det selv, og det er den meget bedre til. Men det er folk ikke klar over,« lyder vurderingen fra Poul-Henning Kamp.

Der bliver også sparet helt unødvendigt på allokeringen af virtuel hukommelse.

»Uha, vi må ikke allokere mere, end vi skal bruge, tænker folk, men i virkeligheden koster det ikke noget at allokere for meget og så ikke bruge det. Det er bare en smule bogføring. Så det koster ingenting at allokere 4 megabyte i stedet for 64 kilobyte og så kun bruge 32 kilobyte. Omvendt er det dyrt, hvis du allokerer for lidt og så skal ind og flytte det hele til en større mængde hukommelse,« forklarer Poul-Henning Kamp.

Han forstår ikke, at universitetsstuderende tilsyneladende slet ikke får den ballast med i udvikler-rygsækken.

»Den slags viden er ikke i nærheden af lystavlen for nyuddannede programmører i dag. Så det var det pædagogiske projekt i Varnish, der fik mig overtalt til at gå i gang med det,« uddyber han.

C-kode i stedet for flueben

Udover at udnytte kernen bedst muligt i Posix-styresystemerne - altså alt fra FreeBSD og Solaris til Linux og OS X - bruger Varnish også et andet trick for at få hastigheden i vejret.

I stedet for en konfigurationsfil med flueben til alverdens indstillinger, skal Varnish konfigureres med en stump kode.

»Det kan være temmelig indviklet, hvad man har brug for at fortælle en cache. Der er det nemmere at give folk et programmeringssprog - hvis sådan, gør sådan - end at have en konfigurationsfil med en masse håndtag at dreje på,« forklarer Poul-Henning Kamp.

Konfigureringen sker i et simpelt sprog, som så bliver kompileret til C-kode og derefter objekt-kode, i stedet for at blive fortolket.

»Dermed kan konfigurationen afvikles med fuld maskin-hastighed, så selvom det bliver kompliceret, har det ingen betydning for performance,« fortæller han.

Har man brug for at tilpasse cachen endnu mere specifikt, kan der indsættes C-kode direkte i Varnish. For eksempel hvis man vil servere forskelligt indhold til de besøgende ud fra deres IP-adresse, hvilket kræver et opslag i en database.

»På den måde bliver programmet åbnet for folk. Det giver en nødudgang, for der er ikke noget mere frustrerende end et program, der kan 99 procent, af det du vil, men hvor den sidste procent er den vigtige. Det har jeg prøvet selv mange gange,« siger udvikleren.

Vedligeholdelsen af Varnish har været betalt af en ordning med Redpill-Linpro, men skatteregler sætter en grænse for, hvor mange penge, der med fordel kan komme fra ét firma. Derfor er Poul-Henning Kamp nu begyndt at udstede 'moralske licencer' hvor de firmaer, som har glæde af Varnish, kan give et bidrag. Planen er at begynde arbejdet med en hel stribe småforbedringer i januar.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (53)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Daniel Eriksen

Et interessandt indlæg. Men lad os være lidt praktiske her.

Når nu der er så mange uddannede mennesker der ikke kender til/ved hvorledes virtuel hukommelse mm. benyttes hvor skal de så starte? Da de er uddannede er kurser ikke en mulighed (jo de er, men bær nu over med mig).

Derfor foreslår jeg at alle der har et kvalificeret bud på hvor man kunne starte med at opdatere sin vide om brugen af disse værktøjer, ligger et link eller to i denne tråd. Det kunne være bøger, websites mm.

  • 0
  • 0
Kim Schulz

Da jeg for år tilbage gik på Aalborg Uni og læste til Datateknik Ingeniør (nu kalder de den vist Software Ingeniør) havde vi faktisk en hel del om virtuel hukommelse, disk IO optimering, IOP, osv osv.
En af de semster-projekter jeg var med til at lave, var faktisk om udviklingen af en distribueret virtuel hukommelse (både memory og disk) til brug i C/C++ kode. En service blev startet på X noder og så ville ens program automatisk finde dem og distribuere memory forbrug ud på de forskellige noder om nødvendigt - selvfølgelig med en del redundans så noder kunne komme og gå uden at det ville skade det "gemte". Her blev systemernes virtuelle hukommelse, multithreading osv brugt i stor stil (og det var forøvrigt et enormt sjovt projekt at udvikle).
Men ellers har PHK ret - Undervisningen i programmering og systemlære er efterhånden røget op på et enormt højt abstraktionsniveau hvor man i bund og grund ikke lærer meget andet end en masse buzz-words

  • 0
  • 0
Jon Bendtsen

Jeg vil give PHK lidt ret. Mig bekendt har DIKU droppet det obligatoriske kerne kursus, og så spørger jeg bare mig selv hvordan de unge så skal lære at drikke kærnemælk?

Men der er givet vis kommet nogle andre kursuser, og selv jeg har da haft nogle i parallel programmering. Så det læres da, men måske ikke i den mængde som PHK ønsker.

  • 0
  • 0
Hans-Kristian Bjerregaard

Problemet er at man er nød til at uddanne sig bredt. På bachelordelen på DIKU har man 2 mdr. til at lære maskinarkitektur og styresystemer (et kursus fylder halvdelen af en blok der tager ca. 8-9 uger). Problemet er at man skal dække meget mere end bare PHK's felt så man kan jo desværre ikke gå særligt dybt i de generelle kurser.

Så som gammel og erfaren er det jo altid nemt at slå de unge og uerfarne i hovedet over at de ikke ved lige så meget på ens kerneområde som en selv ;)

Jeg er dog enig i at de DIKU-fanter der ender med et kode job kunne bruge nogle "håndværks"-kurser men meget af det handler jo også om erfaring som man kun får ved at få tid til at stikke fingrene ned dybt i det problemområde man beskæftiger sig med.

  • 0
  • 0
Klavs Klavsen

du kan jo normalt se på headere hvilken cache boks der bruges, hvis nogen :)

Jeg kan ikke se at brug af Varnish skulle forårsage manglende css filer.

Har du prøvet at skrive til berlingske (der er noget kontakt mulighed via sitet) med en god problembeskrivelse.

Jeg kan garantere dig at hvis det var et problem nogen af journalisterne eller andre derinde bemærkede/kendte til, så stod det højt på listen at få det løst.

Jeg har heller ikke selv set det nogensinde - hvis du kan genskabe det - må du meget gerne sniffe med f.ex. wireshark - og sende snif'et til mig på klavs hos EnableIT.dk (man er vel nysgerrig) - så skal jeg gerne sende info videre til de relevante, da jeg tilfældigvis kender de relevante teknikere :)

  • 0
  • 0
Martin Bøgelund

Problemet er at man er nød til at uddanne sig bredt.

Kunne man evt. forestille sig at lægge den slags ud som valgfrie eller alternative opgaver, eller som emne i en hovedopgave?

Istedet for at lade en hel årgang kode skiplister som obligatorisk opgave f.eks...?

  • 0
  • 0
Casper Bang

Ja og ungdommen kan dårlig nok skrive i assembler længere heller. Dengang da jeg var ung og vi skrev vores egne device drivere når vi fik en printer... dét var tider. j/k

Faktum er jo at man ikke lærer at programmere på universitet. Der studeres computer science, ikke udvikling. Det tog jo da også Linus Torwalds 8 år at tage sin M.Sc. fordi han havde for travlt med at udvikle Linux. Og det er vist meget godt at 90% lærer at stole på de abstraktioner der er til rådighed, ellers kom vi vist ikke rigtig nogen vejne.

  • 0
  • 0
Poul-Henning Kamp Blogger

Så som gammel og erfaren er det jo altid nemt at slå de unge og uerfarne i hovedet over at de ikke ved lige så meget på ens kerneområde som en selv ;

Overskriften er alene Jespers, men ellers har han fint opsummeret hvad vi talte om i telefonen.

Min primære anke er, at alle bøger om computere og programmering, starter med at forklare at "en computer består af CPU+RAM+DISK/IO".

Selvom det på det fysiske niveau er korrekt i et eller andet efterhånden begrænset omfang, så har det absolut intet at gøre med den virtuelle "POSIX" maskine programmer afvikles på idag.

Det er knapt nok en valid model for indlejret programmering mere.

Når alle lærebøgerne skriver noget vås, kan man ikke klandre de nyuddannede at de ikke aner noget om hvad der foregår og det gør jeg heller ikke.

Det er underviserne og lærebøgerne jeg klager over.

Her er slides til mit "Varnish Performance" foredrag, hvor jeg prøver på at forklare blot en lille smule af hvad der foregår, på ca. 45 minutter:

http://phk.freebsd.dk/pubs/varnish_perf.pdf

Poul-Henning

  • 0
  • 0
Jens Beltofte

Så vidt jeg husker benytter Berlingske.dk og andre af deres Drupal websites en Citrix Netscaler til caching af statiske filer. Desuden benytter de Memcache og XCache til caching af forskellige ting i Drupal. Selve HTML outputtet caches vist ikke.

  • 0
  • 0
Carsten Sonne

Der bliver større og større behov for at lære at abstrahere væk fra hardwaren på et passende niveau.

Efterhånden som processorer får flere kerne og opgaverne blive mere krævende og komplekse ift. rå maskin kraft, så bliver vi udviklere mere og mere tvunget til at gå andre veje.

Som udvikler bliver man i den nærmeste fremtid, nød til at sætte sig mere ind i diverse abstraktions API'er, enten direkte i OS API'et eller en endnu højøre abstraktion. I modsatte fald, vil man opleve at 7 ud af 8 kerne på serverene står og idler det meste af tiden. Om 5 år måske 31 ud af 32 kerne der idler.

RAM problematikken er ligeledes velkendt. Ofte vælge mange udviklere at spare på hukommelsespladsen. Det man bare skal tænke på, er hvor meget RAM en computer har i dag.

Eksempelvis er 1 GB, 1.000 MB eller 1.000.000 Kb. Et objekt eller anden datastruktur der fylder 16 bytes, kan man have 10.000 af i hukommelsen og så de de stadig kun 160 Kb eller 0,16 MB. Der er forsvindende lidt ift. 1 GB.

Noget andet er at kunne kende forskel på referencer/hukommelsesadresser og data. Noget andet der ofte forvirre mange udviklere ift. RAM.

Det skaber performans problemer at hente ting på disk, flytte rundt på ting i hukommelsen eller at skulle 'genberegne' ting igen og igen. Specielt hvis man i forvejen kun bruger 1 kerne.

EDIT: Tal rettet.

  • 0
  • 0
Klavs Klavsen

Hvorfor spare på hukommelses pladsen - når det gælder allokering?

AFAIk er pointen med virtuel hukommelse netop at man kan allokere alt det man TROR man kan komme til at bruge - så man laver så få allokeringer som muligt - og så vil kernen sørge for at man rent faktisk kun får den mængde hukommelse som man har skrevet til.

  • 0
  • 0
Lasse Reinholt

Hej PHK,

Nu ved jeg ikke, hvem du præcist kritiserer, da du roder rundt i termerne som programmører, universitetsstuderende, udviklere, osv.

Men du skriver "Folk har ikke en disse forståelse for multithreading...". På bachelordelen på datalogi på de fleste universiteter er trådning altså en temmelig central del i mange kurser. På DIKU skulle vi skrive vores eget pthreads bibliotek i C og i flere kurser indgik spinlocks, deadlocks, mutexes, trådbibliotekoverhead, CPU time slices, etc som en ganske naturlig del. Og der var MPI, PVM, mv. i valgkurser.

Du har sikkert ret i, at mange mennesker kunne have gavn af det, du skriver om, men du må være mere præcis.

  • 0
  • 0
Anonym

Men du skriver "Folk har ikke en disse forståelse for multithreading..."

Jeg undrer mig også over hvem "folk" er, og hvem der ikke ved en disse om multithreading.

I min verden gik vi over til NPTL på Linux fronten for en 5-6 år siden, og afskaffede threadpooling, da en almindelig husholdnings PC på daværende tidspunkt kunne spawne 200.000 threads/sekund.

SVJH fedter PHK stadig rund i threadpooling og forskellige locks.

I øvrigt spiller en god memorymanager en central rolle i det spil, men det er der åbenbart ikke nogen, der nævner (uvidenhed?)

Strenghåndtering er han ligt inde på med 0 terminerede strenge, men da jeg bruger Pascal, er strengoperationer på forhånd optimerede.

Men det er nærmest ovre i P* måling, men med hensyn til undervisningen ved jeg ikke rigtig om det altid er relevant at undervise i den slags.

Langt de fleste udviklinger foregår med mere eller mindre tunge værktøjer, hvor infrastrukturen er givet på forhånd.

Disse lowlevel ting kan man ikke rigtig optimere i ting som Java og .NET, men må håbe på, at de underliggende biblioteker gør det 'godt nok'.

  • 0
  • 0
P P

> Her er slides til mit "Varnish Performance" foredrag

Specielt slide nummer 17 af 38 kan anbefales!
Det er faktisk skræmmende at udviklere har så svært ved så simple performance regler. Unge som gamle så kan slide 17 varmt anbefales. Måske ikke helt de tibud men det er damn close.

  • 0
  • 0
Poul-Henning Kamp Blogger

I min verden gik vi over til NPTL på Linux fronten for en 5-6 år siden, og afskaffede threadpooling, da en almindelig husholdnings PC på daværende tidspunkt kunne spawne 200.000 threads/sekund.

SVJH fedter PHK stadig rund i threadpooling og forskellige locks.

Stig, du lægger en noget bedrevidende holdning for dagen her, så jeg tillader mig at svare igen i samme skuffe:

Stig er et godt eksempel på at "A little knowledge is a dangerous thing": Han overser totalt effekten af de mange lag af caches der er i et system.

Grunden til at jeg "fedter rundt" med threadpooling, er at det er hurtigere at genbruge en thread, end at destruere og spawne en ny.

En workerthread der genbruges, har allerede en hel del af sit "memory-footprint" i CPU'ens cache, hvis du destruere og spawner en ny thread er du så godt som garanteret at der absolut intet er i cache for den ny thread.

Derfor er det også vigtigt, at den thread der genbruges fra pool'en, er den der seneste er dukket op deri, et punkt hvor langt de fleste med vilje eller via deres brug af POSIX condition variables, ender med FIFO scheduling, så den absolut "koldste" thread får næste work item.

Det kan godt være at stigs system kan spawne 200.000 threads/s i et eller andet microbenchmark.

Men Varnish kan levere mindst 175.000 Cache-hits/s, inclusive TCP/IP netværksarbejdet.

Og jeg skriver mindst fordi Kristian løb tør for klienter at tæve den med på det niveau, den var stadig ikke i nærheden af at have travlt...

Og det er sådan set tragedien i en nøddeskal: Fordi folk som Stig ikke forstår eller ikke har tænkt over moderne hardware og OS arkitektur, får de kun en brøkdel af den mulige performance ud af en moderne maskine.

Poul-Henning

  • 0
  • 0
Carsten Sonne

Disse lowlevel ting kan man ikke rigtig optimere i ting som Java og .NET, men må håbe på, at de underliggende biblioteker gør det 'godt nok'.

Nu vil jeg ikke udtale mig om Java, men i .Net er der mange muligheder for at optimere sin kode ift. at ramme cachen og benytte de "rigtige" funktioner for at undgå spildte clock cycles.

Hvis man kender CLR'eren måde at bruge stack og hukommelse på, er der rige muligheder for at optimere. På samme måde er det med streng funktioner, ala memcpy(), strcpy(), strlen(). Jeg vil tro det samme gør sig gældende for Java og JVM.

Vedr. trådhåndteringen er den jo, dybest set, givet af operativ systemet. Evt. højere abstraktioner bygger i sidste ende på den trådhåndtering OS'et stiller til rådighed. Sådan er det for alle frameworks, biblioteker og operativ systemer. Det kan man ikke gøre noget ved hvad enten det er .Net eller POSIX man programmere op imod. Heldigvis.

Til gængæld kan man sætte sig ind i hvordan OS'et håndtere tråde, låse og schedulering etc. Så vil man også vide hvad værdien er i en threadpool. Samtidig vil man vide hvordan man benytter højere abstraktionslag bedre.

Ideen i højere abstraktionslag, er ikke at det skal være nemt. Det er en ganske god sidegevinst, dog også med en bagside. Ideen er derimod at målet kan nåes langt hurtigere og med et bedre resultat f.eks. ift. performance.

I øvrigt er det helt centrale element i den performance der er opnået i Varnish, blot at man skal tænke sig og ikke kun "low-level fetteri"

Designet kan f.eks. bygges op ved at dele opgaverne op, så nogle tråde kan fokusere på det performance krævene, men andre kan hygge sig med det der ikke er så vigtigt. Samtidig skal man gøre sig klart hvad hukommelsestilgang ved brug af forskellige operationer og API kald koster samt hvad låse koster ift. flere kerner.

Det er alle ting, som på ingen måde er specifik ift. POSIX (eller Varnish).

  • 0
  • 0
James Avery

En workerthread der genbruges, har allerede en hel del af sit "memory-footprint" i CPU'ens cache, hvis du destruere og spawner en ny thread er du så godt som garanteret at der absolut intet er i cache for den ny thread.

Derfor er det også vigtigt, at den thread der genbruges fra pool'en, er den der seneste er dukket op deri, et punkt hvor langt de fleste med vilje eller via deres brug af POSIX condition variables, ender med FIFO scheduling, så den absolut "koldste" thread får næste work item.

Jeg er helt enig i, at man som uddannet datalog bør forstå moderne computeres hierarkiske lagerstruktur, virtuelt lager og den slags - på rygraden - ligesom det bør ligge på rygraden, cirka hvad éns højniveaukodes inner loops oversættes som til maskinkode.

Men det skærer mig altså i hjertet at man som applikationsprogrammør anno 2009 stadig aktivt skal fedte rundt med dén slags detaljer for at få ordentlig performance. Det forekommer mig som en oplagt opgave for et paralleliserings-API (og egentlig hellere programmeringssprog, eller endda OS) at sørge for fornuftigt cache-genbrug, minimering af kontekstskift, fornuftig tilgang til lagerhierarkiet, osv.

Det er okay at skulle tænke på, hvis jeg skal skrive et lavniveausbibliotek eller lignende, men det er simpelthen for ærgerligt, at alle stadig skal tænke på den slags, når de skal skrive en simpel applikation. For det gør folk simpelthen ikke, og hvis de gør, så formodentlig oftest ikke godt nok. Resultatet er generelt langsommere eller skrøbeligere software.

(Derudover synes jeg POSIX-trådmodellen som abstraktion af samtidighed er alt for kompliceret til brugerapplikationer, og som det er alt for nemt at lave fejl med.)

  • 0
  • 0
Poul-Henning Kamp Blogger

Min holdning til POSIX threads kan opsummeres i et spørgsmål:

Hvor er pthread_mutex_assert_locked() funktionen ?

Et API der kan "overse" en så fundamentalt vigtig funktion har jeg meget, meget svært ved at tage seriøst.

Poul-Henning

  • 0
  • 0
Troels Liebe Bentsen

Nu havde jeg fornøjelsen af at se overstående artikel som fordrag for et par års siden på FOSS-Aalborg. Og det gav da stof til eftertanke. I modsætning til PHK, så er min stor kæphest dog ikke smålig omgang med hukommelsen eller POSIX threads åbenlyse mangler.

Det er derimod det trådmisbrug man typisk finder en CS kandidat kaster sig ud når der skal laves den mindste smule parallel IO. Ting som non-blocking IO, brugen af select, kqueue, epoll er ikke lige noget man lære på studiet, så de løsninger man typisk ser skyde frem kaster programøren ud i et større helvede af locks og fejl der kun opstår når debuggeren ikke er slået til.

Et andet stort minus er faktisk også at det ikke skalere særligt godt, selvom Linux kernel kan lave røv mange tråde pr. sekund, betyder det ikke at selv samme tråde rent faktisk bruger ressourcerne fornuftigt, og ikke spilder masser af CPU på udnødige context switches eller på at smadre de mange lag af CPU cache en moderne CPU har, fordi en låse skal deles over flere kerner.

At kode tråde korrekt er svært og er noget de færreste virkeligt mestre, så hvorfor ikke lære den store masse af programøre alternativer hvor det er svære er dumme sig. Der er efterhånden masser af frameworks/biblioteker som pakker non-blocking IO ind i forståelige API'er der gemmer det værste legacy væk, fx. libevent til C, Twisted til Python, IO::EventMux til Perl, MINA til Java, etc.

Når de så først har lært hvordan man løser opgaven uden tråde og kan lave applikationer der sagtens kan klare ti tusindvis af parallelle opgaver/klienter/sessions, så kan de så småt begynde at kigger på at bruge core nr. 2-N, hvilket typisk kan klares med en simpel fork eller et par tråde fordi koden allerede er reentrant og trådsikker.

  • 0
  • 0
Carsten Sonne

Paralleliserings frameworks findes allerede i brugbar form. Ormrådet er i vækst, men virker ikke til rigtig at have slået igennem endnu. Årsagen er formegentlig at 2 eller 4 kerner er nutidens standard. Udviklerer (og virksomheder) har ikke rigtig "opdaget" dem endnu.

Der er dog ikke nogen tvivl om, at det kun er et spørgsmål om tid, før de for alvor slår igennem. Når standarden bliver 8, 16 eller 32 kerne, kan man ikke længere ignorer multicore teknologien.

På .Net siden kommer der med v4.0 Task Parallel Library (TPL) og Parallel LINQ (PLINQ).

Noget andet er kontekst skift, cache optimering og API kald etc. Der er ikke nogen nem opgave at automatiserer. Det eneste sted det effektivt kan gøres er vha. compileren.

Compilerer optimere jo langt hen ad vejen koden ift. processor registre og stakken, men at få dem til at optimere API kald og kodestruktur, er nok ikke nogen nem opgave. Så skal den jo nærmest kunne forstå hensigten med kode.

Mange år fremover vil applikationsprogrammøre stadig skulle interessere sig for præcis hvilke API kald de laver samt hvordan de vælger at organisere deres kode på lavt niveau.

For 30 år siden, lavede man programmer vha. tekstfiler. Det gør vi stadig. Visse ting er meget svære at ændre til det bedre (og vel og mærke ikke grundet konservatisme).

  • 0
  • 0
Jacob Christian Munch-Andersen

Men det skærer mig altså i hjertet at man som applikationsprogrammør anno 2009 stadig aktivt skal fedte rundt med dén slags detaljer for at få ordentlig performance.

Definer ordentlig performance. Nu er Varnish jo et serverprogram, og man kan ikke sige meget andet end at det skal levere så høj performance som muligt. At bringe ydelsen i nærheden af hvad hardwaren kan levere bliver aldrig nogen simpel opgave, og heller ej en opgave for en hvilken som helst programmør.

Til gengæld så vil jeg mene at vi andre kunne vise vores taknemmelighed til de programmører som rent faktisk gør sig umage for at skrive den pivhurtige kode som vi andre kan have glæde af, ved ikke med overlæg at smide den hastighed væk igen. Som eksempel er sproget SQL vel om noget en hån mod performance optimering, først laver man et sprog som i sin grundlæggende form lægger op til trawle hele tabellen igennem for at finde en enkelt række ud fra simple præmisser, og så beder man nogle æggehoveder om at få det til at køre ordentligt. Man kommer jo ikke i nærheden af noget der ligner hvad hardwaren kan klare på den måde, på trods af at nogle kloge mennesker har spildt en masse tid på det.

Basalt set er Varnish jo egentlig symptombehandling a la SQL afviklingsoptimering. Rent logisk burde en cachende proxy ikke være en disse hurtigere end en webserver som server statiske filer, webserveren er bare skrevet så meget dårligere at Varnish kan gøre en kæmpe forskel.

  • 0
  • 0
Per Erik Rønne

Tænk, jeg synes nu ellers vi brugte en del tid på virtuelt lager og virtuelle maskiner, da jeg i 80erne læste datalogi på DIKU.
Jeg mener endda at det var helt tilbage på 1. del [det nutidens studenter kalder »bachelordelen] at vi begyndte at stifte bekendtskab med det. Tanenbaum, dat1.

  • 0
  • 0
Torben Frandsen

(...) SQL (...) først laver man et sprog som i sin grundlæggende form lægger op til trawle hele tabellen igennem for at finde en enkelt række ud fra simple præmisser

Jeg tror du satte en del af dine læsere af der.

De præmisser, du bruger til at finde dine rækker kan ikke være helt simple hvis ikke det kan klares med almindelig mængdelære.

Eller misforstår jeg noget her?

  • 0
  • 0
Brian Hvarregaard

For mig ser det ud til at det danske erhvervsliv mere har brug for at man uddanner personer der kan bruges at de fleste virksomheder - det er ikke bitnussere der passer ind her!

Jeg ville hellere at universiteterne brugte tid på at lære de studerende at tage udgangspunkt i kundens krav og ønsker samt at kunne forstå udvikling på et abstrakt niveau og kunne indgå i design/udviklingsteams med grafikere, arkitekter, konsulenter osv. - det vil sige den virkelige verden.

Det er nu engang de færreste virksomheder der har brug for at kunne skrive så optimeret kode som der beskrives omkring Varnish, ved database applikationer er det typisk en brugers oplevelse af tid der er betydende, ikke om jeg udnytter hukommelsen 3,564% bedre end før!!!

Jeg synes det er fedt at der er nogle der er dygtige nok til at skrive så komplekse systemer, men derfra og så til at sige at alle burde lære det. Det er vist bedre bare at smide nogle penge efter PHK og så uddanne de studerende så bredt at de passer ind i så mange forskellige softwareudviklingsbrancher som muligt - det er vist også mere rentabelt at købe sig til det end selv opfinde den dybe tallerken igen.

  • 0
  • 0
Carsten Sonne

@Brian Hvarregaard

I den "den virkelige verden" findes en stor mængde software som performer rigtig skidt. Brugere syntes ikke det er sjovt at side og vente 5-30 sekunder mellem sideforespørgsel i en webapplikation.

Hvis ikke der var fordi brugerne var vant til den slags fra deres desktop (læs: Windows), ville de syntes det var fuldstændig uacceptabelt.

Mere hardware er desværre ikke altid svaret. Derfor er der kun en vej frem,: At tænke sig sig om og have en vis indsigt, eller hvad du kalder "bitnusseri".

  • 0
  • 0
Peter Makholm Blogger

Brian, jeg synes du overser hvad jeg opfatter som en af pointerne ved PHK's resultat med Varnish: Lad kernen gøre det den er god til!

Netop fordi kernen gør et rigtig godt arbejde med virtuel hukommelse, så skal udvikleren af Varnish ikke bekymre sig om læsning og skrivning til disk. Han skal bare mmap'e et passende stykke lager og så sørger kernen for at rykke det rundt mellem de forskellige typer lager.

  • 0
  • 0
Jacob Christian Munch-Andersen

Jeg tror du satte en del af dine læsere af der.

De præmisser, du bruger til at finde dine rækker kan ikke være helt simple hvis ikke det kan klares med almindelig mængdelære.

Eller misforstår jeg noget her?

Mængdelære er ikke en matematikform som umiddelbart kan beskrive hvor lang tid en operation tager på en computer. Selvom du kan sætte en forespørgsel op som et simpelt mængdelæreudtryk er det ikke sikkert at en computer kan afvikle den på en elegant måde.

Hvis du vil forstå databaser skal du først og fremmest forstå indeksering, derefter kan du så begynde at stille spørgsmål som "Hvordan laver man et indeks som passer til den forespørgsel?", og "Har databasen mons tro sådan et indeks?". Hvis du ikke umiddelbart kan finde et ordentligt svar på sådan et spørgsmål så er der en god chance for at forespørgslen vil køre rigtigt langsomt.

  • 0
  • 0
Jesper S. Møller

Hvis du vil forstå databaser skal du først og fremmest forstå indeksering, derefter kan du så begynde at stille spørgsmål som "Hvordan laver man et indeks som passer til den forespørgsel?", og "Har databasen mons tro sådan et indeks?". Hvis du ikke umiddelbart kan finde et ordentligt svar på sådan et spørgsmål så er der en god chance for at forespørgslen vil køre rigtigt langsomt.

Og det er her EXPLAIN PLAN kommer ind i billedet.

(Nej, SQL er ikke perfekt men det indeholder en udmærket afkobling imellem "hvad" (der skal fremsøges) og "hvordan" (det gøres hurtigst muligt) -- det er ihvertfald langt bedre end hvis man skulle skrive sine forespørgsler eksplicit, som i netværksdatabasernes tid).

  • 0
  • 0
Jacob Christian Munch-Andersen

Det er lidt af en catch 22 situation:

Programmører kan ikke skrive DB kode -> Programmører vælger SQL -> Programmører kan stadigvæk ikke skrive DB kode.

Implikationerne af SQL varierer meget, hvis man tager det som det automagiske sprog det er og skriver uden tanke for hastighed så får man sjældent et godt resultat. Folk med lidt mere ide om hvad der foregår kan skrive bedre SQL kode, som dog stadigvæk kompileres et eller andet mere eller mindre upassende sted under kørslen. Der findes prepared statements og andre SQL derivater som principielt burde kunne optimeres til at køre fornuftigt, men virkeligheden halter vist lidt efter.

Og så har vi slet ikke snakket om hvorledes sammenblandingen af data og instruktion i samme streng er et problem først og fremmest sikkerhedsmæssigt.

  • 0
  • 0
Claus Jørgensen

Så uddanelserne har prioriteret generelle kompetancer der kan bruges bredt i erhverslivet, frem for at lære folk at være kernel-hackers, der ikke kan andet.

Undervisning er ikke til for specialisering.

Og man kan nu engang optimere så meget, men hvor tit kan det betale sig at optimere unødvendigt?

  • 0
  • 0
Jacob Christian Munch-Andersen

Og man kan nu engang optimere så meget, men hvor tit kan det betale sig at optimere unødvendigt?

Det kan det per definition aldrig ;-)

Man kan bare ikke altid vide på forhånd om det er nødvendigt at optimere. Men når vi snakker ydelse vil jeg mene at det i dag ikke bør handle så meget om traditionel optimering (bitnusseri) som om at gøre tingene rigtigt på et mere overordnet plan (og det var vist også sådan ca. PHKs pointe). Det er selvfølgelig meget forskelligt fra applikation til applikation, men det kan sagtens gøre en faktor 10 til forskel om man får gjort tingene på en normal gennemsnitlig måde eller får gjort det med lidt mere overblik og får skåret det værste fedt fra. (Her bør webudviklere i særlig høj grad føle sig ramt, databasekald, antal filer per side og ajax kald skal kunne tælles på så få fingre som muligt)

Det nuværende http://edbpriser.dk er et godt eksempel på en ikke meget kompliceret applikation som er gået i knæ pga. dårlig kode.

De små optimeringer kan det for de fleste ikke betale sig at pille ved. (Og her er det så at folk der skriver operativsystemer, serverware og lignende skal vide at det ikke gælder dem, I må meget gerne også gå efter de små procenter)

  • 0
  • 0
Jens Dalsgaard Nielsen

helt enig

men det betyder vel ikke at alle skal lære det samme.

Som Jacob skriver er der brug for folk der kan andet en lave SQL opslag. Det kan da godt være at hvis man eks underviser i OS optimering funktionalitet osv at folk ikke nødvendigvis bruger det hele, men de har (forhåbentlig) lært en måde at gå til tingene på og kan gennemskue andre komplekse systemer osv osv osv.

Og det PHK kan er svært at lære og gennemskue og at bruge, men derfor er det stadig vigtigt at nogen kan det.

Det kan godt være at det at man kan nøjes med 1/3 maskiner i en park ikke umiddelbart er noget stort økonomisk, men strøm vedligehold CO2 køling osv osv (igen) kan da godt være en ide at tage med.

Jeg synes det er lidt nedladende at kalde det bitnusseri når det som med Varnish faktis er noget meget relevant for at få performance på drengen.

Det at Peter M skriver at man bare mmaper osv så tager OS sig af resten - det kan man jo kun komme frem til og finde ud af hvis man ved hvad det drejer sig om ...

Megen OS undervisning er røgen ud der hvor jeg er. I gl dage var der embedded intro med best fit, buddy fit, elevator algoritmer og meget andet godt, desværre ej mere.

Det var min 5€

  • 0
  • 0
Claus Stovgaard

Umiddelbart lyder det som om at PHK efterspørger en mellemting mellem datalogi og data-elektroingeniør. Jeg tænker evnen til at løse komplekse algoritmiske problemer, samtidig med en komplet viden omkring systemet.

Noget af det bedste i optimering til platformen, synes jeg er når høreapperats producenternes fysikere designer algoritmer i matlab og andre høj niveau platforme, så eksekveres det på store computere. Når algoritmerne er designet, så bliver det overladt til ingeniør af forskellige typer for at optimeres indtil det ender på en enkelt chip løsning, på størrelse med en lillefinger negl. Når der så ses på strøm optimeringen også, er det et helt fantastisk system. Her er ”bitnusseri” virkelig en kunstart.

Jeg er selv inden for den embbeded verden, hvor spørgsmål som ”hvad skal der laves VHDL hardware moduler til”, ”hvad skal der ligges som software i en softcore” og ”hvornår skal der benyttes et OS” opstår. I den verden ser jeg bitnusseri som en kunstart der er en del af faget.

  • 0
  • 0
Christian Nobel

Man er altså nødt til at sondere, i stedet for bare at tale om programmering i flæng.

Det PHK laver med Varnish er meget tæt på OS'et, men andre kan lave forretningsspecifikke programmer med andre værktøjer, hvor det endelige produkt kan have en meget høj brugsværdi.

Hvis f.eks. jeg laver et program i Lazarus/MSE/Delphi, ja så munder det ud i en kompilet applikation, hvor jeg sætter min lid til at kompileren tager hånd om "de farlige ting" tættere på OS'et.

Til gengæld er det op til mig at lave et program som har høj anvendelighed (og det skal selvfølgelig være hurtigt osv - fordi man benytter nogle højnivau værktøjer skal man selvfølgelig ikke lave skodkode), men jeg føler intet behov for selv at opfinde den dybe tallerken - der stoler jeg på at PHK og andre er bedre til den del.

/Christian

  • 0
  • 0
Claus Jørgensen

Men når vi snakker ydelse vil jeg mene at det i dag ikke bør handle så meget om traditionel optimering (bitnusseri) som om at gøre tingene rigtigt på et mere overordnet plan

Det vil jeg nu også mene at en del af uddanelsene.

Umiddelbart er problemet nærmere at de fleste unge på uddanelserne er ret ligeglade med performance, da man ikke får ekstra points for god kode, god performance, eller hvad der ligner, hvis det ikke er hvad opgaven går på.

Så at lærene godt kunne forbedre sig på det punkt, der er jeg helt enige.

  • 0
  • 0
Jacob Christian Munch-Andersen

Man er altså nødt til at sondere, i stedet for bare at tale om programmering i flæng.

Det PHK laver med Varnish er meget tæt på OS'et, men andre kan lave forretningsspecifikke programmer med andre værktøjer, hvor det endelige produkt kan have en meget høj brugsværdi.

Hvis f.eks. jeg laver et program i Lazarus/MSE/Delphi, ja så munder det ud i en kompilet applikation, hvor jeg sætter min lid til at kompileren tager hånd om "de farlige ting" tættere på OS'et.

Til gengæld er det op til mig at lave et program som har høj anvendelighed (og det skal selvfølgelig være hurtigt osv - fordi man benytter nogle højnivau værktøjer skal man selvfølgelig ikke lave skodkode), men jeg føler intet behov for selv at opfinde den dybe tallerken - der stoler jeg på at PHK og andre er bedre til den del.

/Christian

Det lyder som om du ikke rigtigt har forstået pointen, man behøver netop ikke at opfinde den dybe tallerken, heller ikke for at skrive noget der er lige så hurtigt som Varnish. OS programmørerne har allerede opfundet den dybe tallerken for os, alt hvad vi skal gøre er at lære at spise rigtigt med den ske der hører til.

  • 0
  • 0
Lars Lundin

Her er slides til mit "Varnish Performance" foredrag, hvor jeg prøver på at forklare blot en lille smule af hvad der foregår, på ca. 45 minutter:

http://phk.freebsd.dk/pubs/varnish_...

Efter at have udført
curl -I vg.no
et par gange, kan jeg ikke dy mig for at spørge til header-linjerne:

X-VG-WebCache: joanie
X-Rick-Would-Never: Let you down

og

X-VG-WebCache: fritz
X-Rick-Would-Never: Give you up

fritz og joanie kunne man gætte på havde noget med load-balancing at gøre, men hvilket formål tjener den anden header-linje?

  • 0
  • 0
Martin Bøgelund

fritz og joanie kunne man gætte på havde noget med load-balancing at gøre, men hvilket formål tjener den anden header-linje?

"Rick" i "X-Rick-Would-Never" må være Rick Astley - du ved, sangen "Never gonna give you up" med linierne:
"[i]Never gonna give you up,
Never gonna let you down
...[/i]"

Har jeg vundet noget nu?

  • 0
  • 0
Lars Lundin

Har jeg vundet noget nu?

Nej, ikke rigtigt, for som (off-)topic angiver, så var det allerede klart. :-)

Efter at have set lignende header-linjer på andre sites (f.ex. /.), så tror jeg bare det er en vittig måde at vise at sitet kører varnish.

  • 0
  • 0
Hans Schou

Programmet 'sort' som er en del af coreutils på de fleste Linux-systemer, bruger tempoærer filer til mellemresultater, når input bliver for stort.
Ex:
[code=bash]
$ strace -eunlink sort < stor-fil > /dev/null
unlink("/tmp/sortj0m1k0") = 0
unlink("/tmp/sortM3Fju5") = 0
[/code]
Hvis der er 1GB RAM og 1GB virtuel RAM fri, og filen kun fylder 50MB, så burde 'sort' kun bruge hukommelse fra systemet.

Egentlig burde 'sort' vel først begynde at lave sine egne temp-filer, når det ikke er muligt at allokere mere virtuel hukommelse, eller hvad?

  • 0
  • 0
Vijay Prasad

Undervisning er ikke til for specialisering.

Min egen erfaring med undervisning er: Indtil man er færdig med bacheloren, så er det grundlæggende viden. Derefter står det så på specialisering (hvorfor mon en kandidat aflevering hedder et "speciale"? :) )

Og man kan nu engang optimere så meget, men hvor tit kan det betale sig at optimere unødvendigt?

(Lige mht. din formulering: Det kan naturligvis ALDRIG betale sig at "optimere unødvendigt". Det interessante er hvornår det kan betale sig at optimere)

En fin mantra fra de tidlige 00'erne. Nu har vi global opvarmning og recession. Folk vil gerne have performance for sine CPU-cycler.

Mvh,

  • 0
  • 0
Dennis Krøger

Egentlig burde 'sort' vel først begynde at lave sine egne temp-filer, når det ikke er muligt at allokere mere virtuel hukommelse, eller hvad?

Er det ikke den sikre måde at sætte OOM killeren igang, hvis der sker noget andet som øger hukommelsesforbruget i systemet?

  • 0
  • 0
Claus Jørgensen

Derefter står det så på specialisering (hvorfor mon en kandidat aflevering hedder et "speciale"? :) )

Men netop kandidat specialer i CS, omtaler da tit bitnusseri og ting som er vigtige for de få specialer der er krævet på det punkt.

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