Fokus på web-caching

Det er veldokumenteret, at hvis man er kandestøber, så er alle problemer i bund og grund manglen på fornuftige kandestøbere.

Det virker også den anden vej: Når man arbejder med et bestemt fagområde, bliver man meget mere opmærksom på dette i sin omgang med resten af verdenen[1].

Jeg roder med web-caching for tiden og derfor er jeg blevet hyperfølsom overfor websider der ikke svarer.

F.eks det nyrenoverede "folketing.dk", som jeg ikke har været alt for imponeret af idag, eller såmænd ing.dk og version2.dk der lejlighedsvist har lidt performance problemer.

Folk med mere handelstalent end jeg, ville ringe til Folketingets Web-master og på vestsjællands siger "Godar' Mit navn er Påul-Hennin' Kaamp, jei haar et gåt tilbuud til Daaj" og dermed lægge grunden til at nyt IT-imperie, men det er ikke lige min stil[2]

Anyway:

Jeg noterer mig, at Folketinget.dk ikke ser ud til at bruge nogen form for web-cache overhovedet og jeg under mig såre.

Ikke over at siten ikke svarer ordentligt, det ville jeg forvente i den situation, men over at de ikke har brugt en eller anden form for web-cache.

For mig lyder folketinget.dk præcis som den slags webside, der vil at blive rendt over ende, hvergang nogen siger noget {idotisk,dumt,smart} (overstreg selv de ikke forventede).

I den daglige drift er belastningen sikkert nogenlunde trummerum, men spidserne bliver heftige, ingen tvivl om det.

Den smule af folketinget.dk jeg har kunnet se, imellem fejlmeddellelserne fra den overbelastede webserver, tyder på et kompetent stykke arbejde.

Og jeg er temmelig agnostisk overfor folks valg af værktøj, når det kommer til stykket, sutter alle CMS'er performance-mæssigt, så vi dropper på forhånd alt det der "de kører XXX/YYY/ZZZ og det er bare for nederen" fanklubberi.

Netop fordi det ser nogenlunde kompetent ud, undrer det mig, at man ikke har overvejet problematikken med at få leveret varen ud over rampen.

Er det fordi "nyheden web-caching" stadig ikke er nået ud til de bredere lag af web-producenter ?

Er det fordi man har set Akamais prisliste og tror det er hvad det koster ?

Eller har man overvejet det og besluttet at det ikke er vigtigt ?

Eller er det noget man satser på at kigge på senere, når støvet har lagt sig ?

Eller er det bare mig der er blevet overfølsom, fordi jeg tror jeg ved hvor godt det kan gøres ?

Håndsoprækning: Hvor mange af jer har overhovedet overvejet, om en ny website skulle bruge et lag web-caching, for at kunne levere varen i myldretiden ?

Hvorfor gjorde I det {ikke} ?

phk

[1] Iflg Eric Idle var en af de allerførste ideer til "Life of Brian", dengang filmprojektet endnu hed "Jesus: Lust for Glory" at Jesus skulle brokke sig over det elendige tømrearbejde hans kors var.

[2] Bortset fra det vestsjællandske selvfølgelig: Lidt bondsk har man lov til at være.

Kommentarer (41)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Loke Dupont

Jeg tror mest af alt det skyldes at de fleste webudviklere ikke tænker på performance. De tænker i features i deres produkt, for det er det der bliver efterspurgt, og det kunderne går op i. De går op i om de kan få god statistik, om det er nemt at bruge, og selvfølgelig prisen på systemet. At overveje om det kan klare presset ved et pludsligt indfald af trafik er ikke noget kunderne tænker over, før siden er bragt i knæ af load.

  • 0
  • 0
#4 Jens Davidsen

En cache-proxy er vel en løsning - men der kunne nu laves mange andre "optimeringer" eller opsætninger som kunne hjælpe også - uden øget kompleksitet som en web-cache vel giver - en hurtig brug af fx. google page-speed tool: http://code.google.com/intl/da/speed/tools.html * Fix af http-headers på static files så de bliver cached ordentligt. * Samling af alle CSS/JS i en fil hver og minify af dem. * Enable gzip compression. * Osv. :-) Hvis man gør det er en web-cache sikkert ikke super nødvendig.... Så hellere kigge på noget som memcached eller ligenede til caching af intense beregninger i web-app'en synes jeg.

Mvh. Jens Davidsen

  • 0
  • 0
#5 Poul-Henning Kamp Blogger

Jeg kan godt se din pointe, men jeg tror at du misser min.

En web-accelerator kan du mere eller mindre bare sætte op med default konfigurationen og begynde at høste fordelene med det samme, uden at give dig til at ændre i dit content eller produktionen af samme.

Dine forslag kræver alle at man stikker fingrene mere eller mindre dybt i substansen, hvilket authoring tools, databaser og meget andet gør til en tricky affære.

Jeg ville under alle omstændigheder høste den lavest hængende frugt først ?

Poul-Henning

PS: @Sven: jeg nævnte ikke Varnish fordi jeg gerne ville tale om det abstrakte koncept web-caching.

  • 0
  • 0
#6 Jens Davidsen

Det er selvfølgelig nemmest bare at smide en web-cache på som laver noget magic ;-)

Men forstår webadmin'en magic'en? og efterhånden skal web-cachen vel også tunes for at cache korrekt? (sender CMS'et fx. allerede forkerte eller manglende http headers ud omkring caching er det jo utrolig svaert for web-cachen at gaette ogsaa? - jeg har ikke rodet med webcaches selv skal det lige siges)

Ting som combine+minify af css/js kan en web-cache vel ikke finde ud af automatisk? eller er der web-caches der har intelligente filtre til sådan noget? En web-cache kan vel ikke fixe et website der ikke er designet til performance - kun afhjælpe performancen lidt...

Jeg synes stadig helst at udviklerne/webadmins skal forstå problemet og tage fat ved roden istedet for at smide mere kompleksitet ovenpå (som kan skabe andre problemer).

Ps: http://www.folketinget.dk/Aktuelt/Gaestebog_betatest.aspx Ingen teknisk feedback endnu dog ;-)

  • 0
  • 0
#8 Nicolai Schlenzig

I mit nuværende job udvikler jeg web-sider til embedded enheder. Vi har i afdelingen flere personer der har stor fokus på performance, men eftersom det er interne systemer, der typisk bruges af < 10 personer ad gangen, så er det ikke lige den del der fokuseres på. Vi er derimod meget opsatte på at skrive god og effektiv kode, der afvikles hurtigt på den givne hardware.

Her har vi altså ikke fokus på caching, ud over det der ligger i HTTP-protokollen/HTML-standarden.

I mit forrige job, hvor jeg var udvikler/tekniker (lille virksomhed), der blev der sat X antal Apache op med static content, på de sider der netop havde problemer under spidsbelastninger.

Det samme gør jeg faktisk også selv, når jeg laver projekter i fritiden for enten mig selv eller andre.

Jeg har dog tidligere rodet med forskellige (reverse) proxy-løsninger, og der er også tidspunkter hvor jeg overvejer at pege nogle "pipes" ind i den Varnish jeg allerede har installeret - men aldrig fået rodet med :)

Lang historie kort, så mener jeg faktisk at have fokus på caching (med nok mere performance generelt).

  • 0
  • 0
#9 Thomas Jensen

Ang. hej,

Som repræsentant for hostingbix med jævnt stor berøring med bredt udsnit af webfyre (udviklere) i .dk tror jeg godt jeg tør konstatere at kendskabsgraden til caching er tæt på minimal.

Hver eneste gang vi oplever et projekt som tænder alle advarselslamper (heavy load i spidsbelastninger) plæderer vi for at tænke caching ind. Det nemmeste for os ville være at sælge hardware, men alligevel møder vi stor modstand hos udviklerne (de skal jo heller ikke betale for jernet).

Jeg ved ikke om de tolker vores sange om caching som om at vi søger at stille dem i miskredit hos beslutningstagerne eller om de oplever at caching generelt bare er bøvlet at håndtere i deres applikation. Men berøringsangst tror jeg måske godt man kan kalde det.

Man kunne også tolke det som en klassisk skyttegravskrig mlmm. udviklere som leverer en applikation og driftsfolk som skal sørge for at skidtet virker.

Ved overdragelsesforretningen og i test virker applikationen jo fint - så når det vælter bare fordi det ryger på forsiden af eb.dk må jo være driftens skyld. Driftsfolk er jo ret beset blot nogen konservative bastards som alligevel siger "nej" til det meste, så det er vel deres skyld.

Så sent som i dag har Varnish reddet os big time da en pressechef fra $nogen smed os en heads up. "Vi gør det her om en halv time".

Det de gjorde kunne 20 spiffy apacher m. loads af ram ikke kunne have overlevet. To vanisher foran sprøjtede blot lystigt TB afsted og gør det stadigt.

Alt i alt - det er en hård fødsel at få alle led til at tænke det ind - men det går da langsomt fremad.

Og så ikke eet ord om alle cms'er som nærmest sætter en ære i at gøre caching så svær som muligt.

best regards tj

  • 0
  • 0
#11 Poul-Henning Kamp Blogger

Jeg er lidt forbavset over at det skulle stå så grelt til som i påstår, men på den anden side kan jeg ikke rigtig pege på argumenter der siger det modsatte, så I har desværre nok ret...

Næste spørgsmål: Hvordan får vi spredt budskabet ?

Poul-Henning

  • 0
  • 0
#12 Anonym

Jeg havde engang ansvaret for driftsprøve på den oprindelige ISB (isb.oio.dk).

Drifstprøven skal selvfølgelig matche SLA'en angivet i kontrakten, hvis der altså er en SLA:

Dengang var kravet, at svartiden skulle holdes under 1 sek. ved 10 samtidige brugere.

Med baggrund i det, lavede jeg et setup, hvor jeg fyrede 10 samtidige tråde af sted for hver 1100 ms (lidt ekstra margin) en times tid om morgenen, og igen om aftenen (inden for den aftalte driftstid).

Det var bare et eksempel, men hvis man havde gjort det, eller gør det generelt, tror jeg hurtigt man vil opdage hvornår man har brug for cache eller ej.

Disse offentlige systemer er normalt købt via udbud, og hosting plejer at indgå. Leverandørerne af disse systemer leverer kun lige akkurat hvad der står i kontrakten (hvis de altså gør det), og hvis der ikke er nævnt noget om spidsbelastninger/caching, vil det helt sikkert ikke indgå i systemet, da det er en ekstraomkostning, set fra leverandørernes side.

Den slags ting skal tænkes ind allerede i kravspec'en i forbindelse med udbudet.

  • 0
  • 0
#13 Thomas Jensen

Der er jo nok desværre mange dagsordener som taler imod en stor udbredelse

  • kun en ganske lille promille af alle danske (Danmark er jo btw. også et bette sprogområde m. relativt begrænsede brugermængder) får nogensinde så mange besøgende at caching bliver en nødvendighed

  • den typiske hostingleverandør ser ofte mere forretning i at sælge et halvt rackskab end rådgive om at tænke smartere

  • den typiske udvikler føler caching som en spændetrøje der forhindrer dem i virkelig at folde sig ud i realtids personificeret content

  • og hvad jeg anser som den største synder - tæt på samtlige CMS'er ligefrem modarbejder fornuftig caching.

Jeg personligt ved sørme ikke hvordan man udbreder kendskabet - en idé kunne være at tage fat hvor hovedparten af de fleste sites fødes i dag. I et eller andet CMS. Man kunne derfor m. fordel sikkert søge at sælge budskabet ind i de communities som er omkring de forsk. CMS'er. En del af de større CMS'er er jo rent faktisk dansk forankrede, så det skulle nok være muligt at møde dem i forskellige sammenhænge og synge sange.

Det er sjældent "ejeren" af løsningen aner en hujende om tekniske løsningsmuligheder - der er derimod en bred kam af leverandører omkring skålen. Skrål efter dem.

best tj

  • 0
  • 0
#14 Jens Davidsen

Google forsøger med deres kampagne "lets make the web faster": http://code.google.com/intl/da/speed/index.html

men det er nok udviklerne, og specielt cms leverandørene der skal have på hatten og læse op på best-practices...

Der ses også indimellem eksempler på at løsninger udviklet/beregnet til små intranet (sharepoint?/osv) sælges som løsninger til kæmpe offentligt tilgængelige websites :-) det er ikke altid udviklernes skyld...

Og så er der også lige det med at skrive en god krav spec. som @TJ skriver. Kunne man ikke lave et standard udkast til det offentlige hvor alle performance/web best practices er udpenslet? de har vel alligevel en del ting der skal overholdes for alle offentlige sider omkring tilgængelighed?

  • 0
  • 0
#16 Søren Bramer

Ligeledes på jaoo brugte Michael Nygard en hel dag på at fortælle om de erfaringer han har samlet gennem årene hvor han har været med til at drive nogle af de helt store sider. Han havde en anekdote om en salgsperson hos ebay der havde sat et produkt på udsalg og sendt et link til alle tidligere kunder. Desværre sad pågældende på et internt net der kører uden om deres cachingservere, og på den måde fik han bragt 200 webservere i knæ på få minutter.

http://www.version2.dk/artikel/12391-jaoo-release-it

  • 0
  • 0
#17 Thomas Jensen

Ang. hej igen

Hvis vi er nået til anekdoternes tid kan jeg også byde ind med en sjov lille en - ikke bare sjov for morskabens skyld, men måske også lidt tankevækkende og med til at underbygge mine ovenstående påstande.

Vi hoster et (i dansk sammenhæng større site). Vi var i et loop hvor vi søgte at få det til at performe bare nogenlunde og arbejdede hårdt på fintuning af caching.

Udviklerne requestede et værktøj således at de selv kunne styre cachingen og i nødstilfælde tømme cachen for givne detailsider. Vi stillede dem et sådant værktøj til rådighed.

Herefter skrev de efter en dags tid stolt at nu havde de lavet en cron som slettede AL cache hvert 2. minut. Stolte fordi det løste deres isolerede problem med noget realtidscontent på en given underside.

10 minutter senere råbte management af os at nu var deres site langsomt igen, og om ikke vi kunne gøre noget. Det hele var jo i al fald vores skyld. Tilsæt selv en passende udråbstegn.

Vi vil så gerne hjælpe - men episoder som denne indikerer at det går lidt op af bakke.

best tj

  • 0
  • 0
#18 Peter Makholm Blogger

Når jeg besøger Version2.dk, så er der i menulinjen et fint lille profilbillede af mig selv, samt mit navn. Disse oplysninger står i den monolitiske HTML-klump version2's sider består af.

Når jeg går ind på www.folketinget.dk står der i top-menuen at jeg har 0 dokumenter i min dokumentkurv. Denne oplysning er ligeledes indskrevet direkte i den monolitiske HTML-side som forsiden består af.

Begge ting gør det problematisk at bruge et eksternt system til web-caching. I den første tilfælde kan serveren sende en 'Cache-Control: private' for dog at kunen anvende browser-cachen. På folketingets sider kan de end ikke gøre det. De bruger 'Cache-Control: no-cache, no-store'.

Teknisk set kan man godt hive sessions- og brugerspecifikt indhold ud i selvstændige requests. Men det kræver at man er webudvikler 2.0 og langt de fleste CMS'er er basalt set skrevet er webudvikler 1.0-typer. Når bølgerne går højt overvejer man i backenden at lave smarte web 2.0-ting.

Et andet problem er at indholdsfolk og politkkere kræver straksopdateringer. Og specielt i politikerversionene kan det være en ikke-triviel mængde sider der skal invalideres. Derfor tager man bare hele webstedet.

Been there and I even have some t-shirts.

  • 0
  • 0
#19 Poul-Henning Kamp Blogger

Begge ting gør det problematisk at bruge et eksternt system til web-caching.

Nej, det gør det faktisk ikke.

Der er to overordnede løsninger på problemet:

  1. Javascript magic.

  2. ESI:includes i web-caching laget.

I begge tilfælde kan du opnå 90+% procent cache-hits.

Poul-Henning

  • 0
  • 0
#23 Erik Cederstrand

Hvad enten det er Sharepoint, Drupal, Plone eller for den sags skyld enhver anden krævende applikation, så er det meget nemt som udvikler at forfalde til den tanke, at udgifter til hardware er kundens hovedpine, og at performance er god nok, så længe kunden ikke brokker sig alt for højt. Det ændrer sig nok ikke væsentligt, så længe et CMS sælges mere på features og teknologi end sider pr. minut.

  • 0
  • 0
#24 Jens Davidsen

please ikke nogen af de javascript tricks...

og hvad med ESI - mere kompleksitet at implementere og med nye layers og muligvis flere http requests per side? Er det ikke bedre at bygge cache ind i web-app'en saa med noget memcached/velocity?

http://developer.yahoo.com/performance/rules.html

ft.dk har alt for mange ressourcer per side og generelt og skal minimere det (de er nok ikke kommet ud af debug mode endnu - det er ihvertfald ikke deployed ordentligt :-)

  • 0
  • 0
#27 Nicolai Schlenzig

Der er intet i vejen med at bruge JavaScript til at forbedre brugeroplevelsen af et givent site, men man skal naturligvis ikke bruge JS for enhver pris alle steder.

Det er korrekt at det giver flere requests mod serveren, og TCP setup tager per definition tid. Men dette skal holdes op imod den kæmpe besparelse i både requests og datamængde man sparer ved at hele siden ikke skal reloades hver gang man ændrer en lille ting.

Jeg taler her om grafik, style sheets, menuer, "framework" html og javascript. Det er typisk dét der fylder meget, og jeg vil godt lægge hovedet på blokken, og påstå at man i 9 af 10 tilfælde får en meget bedre brugeroplevelse, hvis man bruger JavaSCript korrekt.

Ja, så er der selvfølgelig special cases hvor projektet har større prioritet mod simplicitet og måske understøttelse af gamle browsers eller tekstbaseret browsers - men det vil jeg slet ikke komme ind på, for det er en helt anden snak.

Jeg kunne nok fortsætte meget længere endnu, men skal have frokost nu ;)

My 2 cents.

  • 0
  • 0
#28 Nicolai Schlenzig

Jeg glemte lige at komme tilbage til tråden... men vil i den sammenhæng sige, at det netop falder i god tråd med caching at bruge JavaScript/AJAX til at hente data/elementer.

Du ikke alene minimerer mængden af data, men du undlader helt at hente mange ting flere gange end højst nødvendigt.

Bevares, så har vi "304 - Not modified", men det udmunder stadig i et HTTP request, som stadigvæk tager tid og ressourcer at sætte op.

Så kan man diskutere om ens JavaScript så bruger for mange requests til at opbygge en given side, men det er igen et designspørgsmål, hvor man nok har lige så mange muligheder, som der er veje til Rom ;)

  • 0
  • 0
#30 Thomas Jensen

SV: SV: SV: ang. hej

Sjovt som en ganske relevant problemstilling og diskussion kan dreje sig væk fra fokus .)

Ingen tvivl om at alverdens problemer kan løses hvis man bare liiiige (omskriver sin applikation).

Fakta er at man ikke bare lige omskriver sin applikation når man når dertil i processen af mange besøgende giver problemer.

En mere relevant diskussion er at diskutere hvorledes man undgår overhovedet at komme dertil. Hvor er det kæden hopper af gang på gang ?

Og dette uanset hvilke tekniske løsningsmuligheder man da bare liiiiige kan kaste efter sin monstrøse applikation.

I 9 ud af 10 cases som kommer forbi mit bord vælger kunden at hardwareskalere.

best tj

  • 0
  • 0
#32 Jens Davidsen

Hvad med en simpel two-pass template rendering?

Dvs. først render templaten uden bruger/session data - og cache dette resultat server side i en cache. herefter kan denne cached version renderes igen med bruger/session data uden noget "tungt" db/fil/andet opslag.

Det løser så stadig ikke problemet med ft.dk's mange js/css/images, og no-cache http-headers på det.

Jeg tror dog det ender med som @tj siger - og at der ligger en bestilling på ny hardware på bordet imorgen :-)

  • 0
  • 0
#33 Anonym

Stig: hvor godt er de offentlige projekter overhovedet specificeret?

Det kan jeg ikke udtale mig om generelt.

De projekter jeg har været med til har været svingende, men den røde tråd var, at der ikke var (nævmeværdig) IT kompetance til stede hos deltagerne, men at man hyrede eksterne konsulenter til den slags (herunder undertegnede).

En væsentlig problemstilling var, at man ikke genbrugte viden (og folk) fra tidligere projekter, da man hellere ville 'prøve selv'.

Jeg skriver i datid, for jeg besluttede for nogle år siden, at mit liv er for kort til det offentlige.

Hvolken metode bruger de?

I en del tilfælde var kravspec'en allerede lavet, men det bærer præg af 'kaffeslabberads' - metoden. Altså en masse (usammenhængende) impulser, der resultere i en nærmest checkliste i stedet for en sammenhængende beskrivelse af forretningsgange, og daf afledte krav.

Det er jo mange andre ting end performance der skal specificeres

Ja, men nu er emnet performanceproblemer/caching, så derfor nævnte jeg det med driftsprøven.

Hvis man havde foretaget en driftsprøve på folketinget.dk, havde man højst sandsynligt opdaget problemerne.

I den forbindelse er det nok værd at nævne, at man ikke i et udbud må bede om specifikke produkter, men 'funktioner'.

Man kan med andre ord ikke kræve, at der f.eks. er cache på en given site, men man må styre det via SLA'en.

Her er det f.eks. også vigtigt at forstå begrebet samtidige brugere.

I Virk.dk opererede man med samtidige brugere analogt med 'sessions', så hvis jeg ser siden, og du ser den 1 minut efter, tolkes det som 2 'samtidige brugere'.

En anden ting, når vi er i anekdoterne, var driftsprøven på ISB'en.

Her havde Accenture/Microsoft lavet et test setup baseret på et MS tool. Der er den særlige problemstilling, at MS, via wininet, kører med keep-alive på connection, så trådene på serveren bliver genbrugt. Det afspejler jo ikke det virkelige liv, så mit tool lavede jeg med connection:close og lukkede forbindelsen eftere hver request.

Allerede ved de 10 samtidige req/sek, kunne man se, at .NET serveren var tæt på at stå pga. Garbage collectoren.

Jeg lavere et relativt detaljeret udtræk over nogle minutter, og her kan man tydeligt se problemet: http://w-o-p-r.dk/images/testdoc1.5.minutter.20030112.svg Bemærk at mimetypen er application/octet-stream, og ikke image/svg+xml, men det har jeg ikke kontrol over på Unoeuro's server. Så det er muligt den skal downloades for at kunne vises. Endvidere kræver det en plugin hvis man bruger IE, da MS ikke ønsker at understøtte denne standard.

Men mit gæt er, at folketinget.dk bukker under for det samme problem (GC), der har en kedelig tendens til at sætte skidtet i stå.

Nok om det, men hvis man har en fornuftig SLA, så er det leverandørens problem at løse det (uden ekstra omkostninger).

  • 0
  • 0
#34 Anonym

Overordnet har jeg lidt tavshedspligt, og loyalitetsforpligtelse, så jeg vil ikke udtale mig ret meget om omstændigheder, men jeg fandt min afsluttende rapport om opfyldelse af SLA'en for ISB.

Da ISB'en kun kørte i ca. 5 år, og den ikke eksisterer mere, føler jeg dog ikke at jeg overtræder nogle tavshedspligter.

Men hvis det kunne være til hjælp for fremtidige projekter, så er der her et eksempel på en driftsprøve og rapport: http://w-o-p-r.dk/docs/ISB_Driftsproeve.2003.01.31.doc

Hvorvidt der er udført en egentlig driftsprøve for eks. folketinget.dk, ved jeg dog ikke noget om.

  • 0
  • 0
#35 Jesper Louis Andersen

fordi webcaches gør ting "gratis" for mig. Jeg kan lave "grimme" ting såsom at route alt statisk data gennem et fortolket sprog uden at prisen for dette er specielt høj. Så længe jeg husker mine caching headers så webcachen ikke bliver forvirret.

Det giver mig så en lang række fordele i koden fordi jeg kan redefinere og flytte filer rundt som det passer mig grundet routingen i kodelaget.

Man kan i den grad spille med sin webcache og opnå en række fede fordele som gør arbejdet med siden meget nemmere. Og prisen for at installere en webcache er næsten 0 arbejdstimer. Det kan ikke være bedre. Dertil kommer at en cache som Varnish tilmed leverer hastigheden.

Men - det er stadig bare en del af godt webdesign, som før skrevet. Man skal også tænke i andre ting såsom hvordan browseren spiser data fra siden og renderer det, hvor hurtig en forventet netværksforbindelse er osv.

  • 0
  • 0
#36 Anonym

fordi webcaches gør ting "gratis" for mig. Jeg kan lave "grimme" ting såsom at route alt statisk data gennem et fortolket sprog uden at prisen for dette er specielt høj

En anden fordel er, hvis vi snakker GC systemer (.NET/Java f.eks), at man giver GC'en 'tid' til at rydde op i de dårlige programmørers efterladenskaber, så systemet ikke står af i en sky af hestep*rer, når memory er sluppet op.

Det burde næsten være et krav, at GC systemer leveres med et cache system, så man undgår disse nedbrud.

  • 0
  • 0
#37 Jesper Louis Andersen

@Stig:

Problemet med GC er egentlig ikke så meget GC dog. Det er nærmere de programmører som ikke aner hvad der sker når de allokerer et objekt og holder på det i længere tid. Eller at Java (specielt Java af en eller anden grund) har en ideologi om at man skal wrappe det samme objekt 6-8 gange i en applikationsstak. Prisen er mindst et GC-headerobjekt per wrapping og det gør bare ondt: Din (L1/L2) cache er smadret til ukendelighed, din heap fylder et par gigabyte, din GC kommer på overarbejde.

Hvis man derimod fatter GC kan det blive ekstremt billigt. At allokere et nyt objekt er lig med at flytte en pointer og checke om den er kommet over grænsen for en collection. At frigøre et ubenyttet objekt koster 0 (Det bliver ikke rørt overhovedet i en 2-space collector som javas yngste generation er). Der er en pris for benyttede objekter fordi de skal kopieres dog. Derfor er det, som tommelfingerregel, rimeligt vigtigt ikke at gøre sin levende heap større end højest nødvendigt hvis man har sin performance kær (og samtidig skal man holde allokation-rate nede. Det er nemmere i visse sprog end andre :).

Når programmørerne er dårlige er det en rigtigt god ide med en webcache. Så kan man overlappe GC med levering af data fra webcachen - og når man nu har en kerne eller 2 i overskud på moderne CPU'er så er den sag meget nemmere.

  • 0
  • 0
#38 Carsten Gehling

I onsdags havde 21-tvavisen lavet "reklame" for min hjemmeside, oooog..... Ja den overlevede da, men mange besøgende måtte desværre gå forgæves. :-)

Det var virkelig et "surge", og det var siden bestemt ikke gearet til. Jeg havde lige ugen forinden lagt alle vores statiske filer (pt. eksklusiv bruger-uploadede billeder) over på Amazon S3, og havde jeg ikke gjort det, ja så tror jeg mange flere var blevet smidt af.

Jeg kan derfor bestemt anbefale eksterne asset hosts.

Så for mig er caching gået hen og blevet meget aktuelt. Og det er en svær nød at knække, for vores forside (som selvfølgelig er den mest belastede) består af indhold fra så mange datakilder på sitet. Så jeg grubler over en opdaterings strategi. Jeg vil jo selvfølgelig gerne have siden cachet, omvendt skal den cache også genskabes, så snart indholdet fra en af delsystemerne ændrer sig.

Jeg ser ikke rigtig muligheden for en "ekstern løsning" på dette punkt. Jeg hører gerne gode råd :-)

  • Carsten
  • 0
  • 0
#40 Carsten Gehling

Ja da :-) det er www.gipote.dk

Jeg har tænkt på den med Cron. Men hvis en bruger opretter en annonce eller et indlæg i forum, el., så vil vi gerne have det på forsiden med det samme. Med en cron vil forsiden hurtigt være forældet på tidspunkter med meget aktivitet.

Jeg arbejder lidt med en strategi om, at hvert delsystem skal "sladre" til en central service om, at der nu er sket en tilføjelse af nyt indhold. Denne centrale service skal så holde styr på, fra hvilke delsystemer, der faktisk trækkes data til forsiden og så udfra det bedømme, om cachen skal opdateres.

Samme strategi vil jeg kunne benytte på andre af hjemmesidens meget belastede dele.

Tilbage er der så de - per bruger dynamiske - indholdsfelter. Som f.eks. "Velkommen Carsten". Der tror jeg, at jeg vil prøve med førnævnte javascript løsning.

  • Carsten
  • 0
  • 0
#42 Carsten Gehling

Det lyder ikke helt dumt det Varnish. Jeg skal lige læse lidt mere om det, for i mit tilfælde vil det være nødvendigt at tilgå brugerens session data.

Anyway det var faktisk heller ikke min mening at blive lavpraktisk. Blot at indføre et argument om, at caching kan blive nødvendigt - især når man mindst venter det. :-)

  • Carsten
  • 0
  • 0
#43 Donald Axel

Jo jeg overvejede at bruge Varnish til et lille site med 20-30 journalist-studerendes præsentation af sig selv. Sitet bliver belastet mens de opretter deres weblogs og i den uge, hvor praktikstederne kigger dem i sømmene. Der ville man formentlig have glæde af det, men min tid var knap og jeg var syg.

  • 0
  • 0
#44 Anonym

@Jesper:

Problemet med GC er egentlig ikke så meget GC dog. Det er nærmere de programmører som ikke aner hvad der sker når de allokerer et objekt og holder på det i længere tid.

Jeg skrev også [b]dårlige[/b] programmører ;)

Hvis man derimod fatter GC kan det blive ekstremt billigt.

Jeg håbre ikke det er mig du hentyder til.

At allokere et nyt objekt er lig med at flytte en pointer

Inden for Delphi-verdenen, har vi noget, der hedder reference counting, som netop blot returnerer en pointer til et eksisterende objekt (med mindre man er den første).

At frigøre et ubenyttet objekt koster 0

Ditto med reference counting (dog koster det 'lidt', da blokken bliver markeret available i memorymanageren.

og når man nu har en kerne eller 2 i overskud på moderne CPU'er så er den sag meget nemmere.

Nu relaterer jeg denne her artikel til folketinget, og der havde man vel netop ikke et par cpu'er (eller cores) i overskud?.

Men GC ctr. ikke GC har været diskuteret siden sidste årtusinde, og man kan lave performancetest, der viser at GC er bedre, og omvendt.

I bund og grund er det afhængig af den aktuelle applikation, og ikke akademiske diskussioner(IMO).

  • 0
  • 0
#45 Jesper Louis Andersen

@Stig:

Nej, jeg hentyder så absolut ikke til dig. Du giver generelt udtryk for at være en kompetent person når man læser debatten. Tak for det.

I forbindelse med folketinget lader det åbentbart til at man har haft lidt for store portrætbilleder. I den forbindelse er det ikke ualmindeligt. Fordi diverse journalister ikke kan finde ud af det der med en original og en nedskaleret kopi valgte mange bare at smide det "ultimative" billede ind over det hele og lade browseren om at nedskalere. Ellers bliver der nogen gange trykt hamrende elendige billeder fordi det er thumbnailet/kopien der har været offset-master. Jeg har set det på en del sites efterhånden og ovenstående plejer at være søforklaringen.

Personligt håber jeg dog at man med tiden er har lært det lidt dybere.

  • 0
  • 0
#46 Christian Schmidt Blogger

Når jeg besøger Version2.dk, så er der i menulinjen et fint lille profilbillede af mig selv, samt mit navn. [...] Når jeg går ind på www.folketinget.dk står der i top-menuen at jeg har 0 dokumenter i min dokumentkurv. [...] [Det] gør det problematisk at bruge et eksternt system til web-caching.

Ikke nødvendigvis. Langt de fleste brugere på sitet vil ikke lægge noget i deres dokumentkurv og får derfor det samme at se. Først når de gør det, er det nødvendigt at sætte en cookie. Hvis du sender en "Vary: Cookie" header, vil alle brugere, der ikke har cookies sat på domænet, kunne få serveret siderne direkte fra en proxyserver uden at involvere selve webserveren.

Det samme gælder for Version2.dk, hvor alle de anonyme bruger kan få indhold fra proxyserveren, mens kun dem med en sessioncookie bliver stillet igennem til webserveren.

(Det er en streg i regningen,hvis man bruger fx Google Analytics, idet de sætter en brugerspecifik cookie for alle brugere, men disse cookies kan man med lidt tricks sætte sin reverseproxy til at ignorere)

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