Specs?

Nu er folk her jo teknisk interesserede, så lidt specs på noget nyt grej kunne jo være spændende at høre om? :)

/Anders

Spejling (uucp )

Hvad med spejling af server? Laver man ikke det mere?

Debug i drift?

Jeg har kastet et blik på kildekoden, den kode som jeg kan se med min browser. Jeg bruger Firefox, og i det følgende vil jeg antage at min browser ikke har tilføjet ekstra tegn. Altså, forudsat(!) det:

Jeg kan se, at koden er væsentlig bedre end hvad man typisk ser, altså meget fint, bravo! :-)

Men: Kildekodens formatering er en manuelt lavet "debug"-formatering, det kan jeg samtidig se, og det er ikke (helt) optimalt når systemet er i drift. Jeg taler kun om en marginal her, slet ingen katastrofe.

For eksempel (og som man ofte ser): Programmøren har indsat en masse TAB-tegn i koden, for at gøre kildekoden lettere at overskue når han/hun leder efter fejl, som er optimalt når man udvikler systemet, men disse ekstra tegn kan godt fjernes fra serverens programmeringskode, i den kopi af systemet som man sætter i drift, og i så fald vil brugerne opleve en hurtigere download-tid og en hurtigere fremvisnings tid i browseren. Måske er der kun en marginal at hente her, det kommer an på mængden af overflødige tegn, som jeg ikke har gidet at analysere på.

Et andet eksempel: I koderne i browseren bliver der også anvendt meget lange variabelnavne, fx:

102804-sejl-raket-fra-vestas-skal-op-paa-95-kmt-til-havs

Sådanne variabelnavne er udmærkede, fordi de er lette at forstå når man leder efter fejl i koder, men hvis sider indeholder mange af sådanne variabelnavne, da fylder/koster det ekstra transmissionstid og også fremvisningstid i browseren, i forhold til hvis man anvendte allerkorteste numre som variabelnavne.

Et tredje eksempel: Kildekoden indeholder mange henvisninger til foldere på serveren, og endnu flere henvisninger til klasser i koder, og alle disse er skrevet som fuld tekst, det vil sige med mange tegn, som er let at overskue når man leder efter fejl, men i drift kan man nøjes med ganske korte numre, som vil fylde mindre.

Jeg vil tro, samlet set, at der er en del procenter at spare i sidernes størrelser (de sider der bliver sendt til brugerne). Jeg vil dog ikke ligefrem anbefale at man fokuserer på dette, fordi der kan være meget vigtigere ting at fokusere på, men hvis Ingeniøren ønsker at optimere hastighed og minimere belastningen på serverne og deres ledning til Internet, da bør man kigge på sådanne detaljer.

Og en bemærkning: Det er ikke helt ufarligt, at bede en programmør om at udluse sådant ekstra fyld fra serverens koder, fordi et sådant arbejde introducerer en latent risiko for at udluse en anelse for meget. I stedet bør en programmør skrive en lille oversætter der tager en kopi af alt kode og gennemsøger kopien for alt overflødigt skidt, og eksporterer en udrenset version af systemet, og det er da den version som man anbringer på serveren. Jeg siger ikke, at dette er en let og hurtig opgave, men det er hvad man kan gøre, hvis man jagter en højere performance i et system der er i drift.

I øvrigt må jeg sige, at jeg stort set altid er tilfreds med måden som denne site kører og fungerer. Brugerfladen er simpel og let at forstå, som er guld værd.

Re: Debug i drift?

Ja og da det er database-serveren der var problemet og ikke netværket, så skal du nok se at det nok ikke ville gøre det store fra eller til.

Re: Debug i drift?

Jeg har kastet et blik på kildekoden, [...]

Carsten, vi har altså ikke 14.4 modems mere...

Tro mig, de optimeringer du foreslår er helt uden effekt nu om dage, der skal helt andre boller på suppen.

Læs om Edge-Side-Includes f.eks.

Poul-Henning

Re: Re: Debug i drift?

Tro mig, de optimeringer du foreslår er helt uden effekt nu om dage, der skal helt andre boller på suppen.

PH: Jeg er delvist enig. En marginal for hver bruger, fuldstændig sandt. Jeg er også enig i, at jeg på serversiden har fat i et marginal problem i forhold til andre problemer.

Alligevel: Hvis du studerer siderne fra Google, da vil du konstatere at der intet usynligt fedt er. Google er ganske vist enormt belastet af trafik og behøver at optimere på alle kanter, men en ganske lille website som Ingeniøren (i forhold til Google) kan have en tilsvarende udfordring i sin egen skala, dvs. i forhold til budgetter. (Jeg kender intet til Ingeniørens økonomi.)

Hvis for eksempel at Ingeniøren er i den situation, at belastningen har en grad, så der er behov for en server mere, da kan en udrensning af "usynligt fedt" på siderne (hvis dette er nemt og billigt at gøre) måske udskyde behovet for en ny server i nogle måneder, som måske kan redde et problem med et årsbudget, hvis man tilfældigvis har et problem. Udskydelse af IT-investeringer er en virkningsfuld måde at dæmpe sine omkostninger, naturligvis forudsat at man ikke ødelægger sin forretning.

Re: Re: Debug i drift?

Ja og da det er database-serveren der var problemet og ikke netværket, så skal du nok se at det nok ikke ville gøre det store fra eller til.

Det kommer an på, hvad Ingeniøren udtrækker fra database. Programmeringskoder kan være lagret i en database, og hvis disse er af runtime fortolket type, da vil eventuelle overflødige tegn i koden være en del af belastningen af databasen og dens forbindelse til webserverne. Hvor flaskehalsene er, kræver altid en nærmere analyse.

At jeg har grebet fat i et så marginalt emne, skyldes alene at dette emne er det eneste emne som vi som brugere (uden intern viden) har mulighed for at analysere på (koden som vi kan se i vore browsere).

Re: Re: Re: Debug i drift?

Et andet eksempel: I koderne i browseren bliver der også anvendt meget lange variabelnavne, fx:

102804-sejl-raket-fra-vestas-skal-op-paa-95-kmt-til-havs

Det kaldes søgemaskineoptimering. Det giver ekstra bonus hos Google når søgemaskinen skal rangordne søgeresultater, hvis søgeordet indgår i URLen. Derfor ser du dette mønster på alle større nyhedssites.

Skulle man endelig ønske at spare de få bytes, så giver det langt mere at komprimere siden med gzip. De fleste browsere kan finde ud af at dekomprimere html pakket med gzip. F.eks. fylder nærværende side 57606 bytes ukomprimeret og 12936 bytes komprimeret. Det giver næppe særlig meget ekstra at fjerne overflødige tegn før komprimering.

Re: Re: Re: Debug i drift?

Ja og da det er database-serveren der var problemet og ikke netværket, så skal du nok se at det nok ikke ville gøre det store fra eller til.

Det kommer an på, hvad Ingeniøren udtrækker fra database. Programmeringskoder kan være lagret i en database, og hvis disse er af runtime fortolket type, da vil eventuelle overflødige tegn i koden være en del af belastningen af databasen og dens forbindelse til webserverne. Hvor flaskehalsene er, kræver altid en nærmere analyse.

At jeg har grebet fat i et så marginalt emne, skyldes alene at dette emne er det eneste emne som vi som brugere (uden intern viden) har mulighed for at analysere på (koden som vi kan se i vore browsere).

Ing.dk kører på en XOOPS platform, hvor du har masser af muligheder for at nærstudere i hvert tilfælde noget af den kode, som kører på websitet :)

Dernæst: Hvis man begynder at tælle tabulator-tegn og argumentere imod læsbare URL'er, tror jeg ikke man er helt i tråd med nutidens web-udvikling (ikke ment som en personlig fornærmelse, men en konstatering af, at der er mange grunde til at dette ikke er dér man først skal se efter optimeringsmuligheder).

Hvis man som Google vil skære ned på de bits, som transmitteres til brugeren, skulle man snarere se på gzip-komprimering (selvom dette vil øge belastningen af webserveren)

Ing.dk og Version2.dk kører (så vidt jeg kan bedømme) på den samme databaseserver og (formentlig) samme webserver og har i det forgangne år haft en stigning i trafik (sidevisninger) på ca. 20% (kilde: FDIM), så jeg er ikke overrasket over, at der kommer flaskehalse.

Hvis man skulle se på optimeringsmulighederne for Ingeniøren for at tage noget af trykket fra databaseserveren er svaret nok snarere caching.

En overvejende del af de besøgende på ing.dk og version2.dk er formentlig anonyme besøgende - altså besøgende, som ikke er logget ind som brugere - og langt de fleste elementer på siden vil ikke skulle afhænge af, hvem der ser dem. De vil kunne caches i kortere eller længere tid og derved nedsætte belastningen for både webserver og databaseserver.

Da jeg arbejdede på Ingeniøren så vi på Varnish og talte om, hvorvidt vi kunne implementere sådan én foran webserveren. Vi kom aldrig særlig langt med denne snak, men jeg ville nok genoplive og kaste lidt ressourcer efter den.

Re: Re: Re: Re: Debug i drift?

Det kaldes søgemaskineoptimering.

Baldur: Tak. Den detalje havde jeg overset, selvfølgelig meget vigtig, enig.

Re: Re: Re: Re: Debug i drift?

Da jeg arbejdede på Ingeniøren så vi på Varnish og talte om, hvorvidt vi kunne implementere sådan én foran webserveren. Vi kom aldrig særlig langt med denne snak

Den slags er en speeder, enig. Men, nu til driftsøkonomi over en længere årrække, som ofte er min fokusering: Hjemmesider opfører sig som en pyramidalsk kaskade af omkostninger, for eksempel:

A. Man nøjes med statiske sider: Næsten intet behov for hardware, og næsten intet behov for klogt personale. (Den tid er forbi for længst.)

A2. Man nøjes med "dynamik" på interne computere der anvendes af fx nogle redaktører, og disses arbejde sørger en kompiler for at oversætte til statiske sider, der publiseres på en server. Nu stiger omkostningerne til personale, men ikke til hardware.

B. Man anvender dynamiske sider: Et større behov for hardware, og også et større behov for klogt personale, og man introduceres for problemer med datasikkerhed.

C. Man begynder at anvende databaseserver. Nu stiger kunsten og udgifterne.

D. Man begynder at anvende balancering af servere. Her begynder man at få behov for, samlet set, egentlige eksperter, som koster dyrt.

E. Man begynder at anvende særlig hardware, fx til kryptering, og fx til lynhurtige adresseringer af et meget stort antal parallelle servere. Nu begynder man også at kunne mærke sin forsikringspræmie, og sin el-regning.

F. Man begynder at anvende matematik og datalogi på avanceret niveau, totale optimeringer af alt. Først nu, vil de relative udgifter begynde at falde i forhold til forretningens udbytter, er min forudsigelse.

Det er i dette billede, at jeg altid anbefaler at man udrenser mest muligt fedt, for at forsinke det næste omkostningstrin på stigen.

Re: Re: Re: Debug i drift?

Alligevel: [...]

Googles problem er båndbredde, det problem har ing.dk/version2.dk ikke (endnu).

Poul-Henning

Re: Re: Re: Re: Re: Debug i drift?

Det er i dette billede, at jeg altid anbefaler at man udrenser mest muligt fedt, for at forsinke det næste omkostningstrin på stigen.

Grunden til at folk installerer Varnish, er at det tager en komplex load på database-serveren og gør det til en triviel load på Varnish serveren.

Uanset hvad du måtte komme op med af microoptimeringer Carsten, så kan ingen database server hamle op med, at Varnish kan levere et cache-hit med kun 7 systemkald, heraf 4 timestamps alene af hensyn til logfilerne.

Jeg er 100% enig med Jan i, at du er 10 år bagefter det teknologiske stade på web-servere.

Poul-Henning

Re: Re: Re: Re: Re: Re: Debug i drift?

10 år bagefter det teknologiske stade på web-servere.

I den forstand, har jeg aldrig været hverken forud eller ved siden af ... Jeg er den type, der har haft ansvaret for at træffe beslutninger om hvilke mennesker at ansætte, dvs. med hvilke kompetencer, i forhold til hvad mennesker behøver at få i løn, og i forhold til om mennesker overhovedet er mulige at ansætte i et givent geografisk område, og, om det er muligt at vedblive med at beholde disse ansatte og samtidig undgå et fremtidigt lønpres. Disse overvejelser har jeg været involveret i, at krydse med brugsbehovene for brugere af applikationer, og ud fra disse kombinerede behov har jeg været med til at træffe en tredje art af beslutninger, om hvilke IT-producenter (hardware og software) som er værd at satse på med hensyn til fremtiden, om selskaberne vil kunne overleve, og om det er sandsynligt at de vil kunne produkudvikle deres teknologier i mindst samme tempo som alternative leverandører. Ved at afveje alle disse ydre faktorer, har jeg deltaget i, eller været ansvarlig for, at godkende og afvise, en slags udformning af politik. Og så, først da begynder man at kigge på konkrete måder at anvende software og hardware, med meget stort fokus på at holde det simpelt og med så få forskellige teknologier i brug på én gang, for at dæmpe behovet for ansattes viden mest muligt, for at spare på lønudgifter.

Denne tænkning er stik modsat af hvad IT-fageksperter ønsker sig, for de er så kloge at de kan overskue de fleste teknologier inden for deres fagområde, og de har personligt ingen bekymringer, fordi de kan finde sig et andet job så let som ingenting. En arbejdsgiver behøver at tænke langsigtet, og derfor, af refleksvanetænkning, kan jeg finde på at give små anbefalinger som får fagfolk til at ryste på hovedet, eller, jeg kan finde på at forlange at papæsker skal fjernes straks og at gulvet skal være rent, fordi jeg måske netop da tænker på selskabets brandrisiko, mens nogle IT-teknikere snarere tænker på at udskifte fx en server hurtigst muligt.

Oven i dette er der DotCom-filosofien, som de fleste af os har håbet på at deltage i, at score guld ved at vokse på teknologisk måde så hurtigt som overhovedet muligt, uanset omkostninger, for i sidste øjeblik at blive reddet ved at sælge sig selv dyrt. Denne usikre faktor har haft stor betydning, men, desværre, viser erfaringen, at det kun er ganske få selskaber der har haft held med at overleve på den filosofi. De fleste selskaber, der har en hjemmeside, er begyndt at indse den daglige driftsøkonomi, og som fx betyder, at selskaber der befinder sig ude i provinser, stort set ikke kan løfte opgaverne, fordi de ikke kan skaffe ansatte med tilstrækkelig brede ekspertiser, i hvert fald med behov for at tænke sig grundigt om på stenalder-måde. Ingeniørens ansatte og leverandører befinder sig velsagtens midt i København, hvor der er masser af muligheder for at tiltrække dygtige IT-fageksperter, endda studerende som er billigt, en noget lettere situation end jeg har oplevet andre steder, altså er jeg en geo-dinosaur ...

Re: Re: Re: Re: Re: Re: Debug i drift?

Uanset hvad du måtte komme op med af microoptimeringer Carsten, så kan ingen database server hamle op med, at Varnish kan levere et cache-hit med kun 7 systemkald, heraf 4 timestamps alene af hensyn til logfilerne.

Har du overvejet (eller måske allerede implementeret) at 'forzippe' data ?

Altså at (g)zippe data når de bliver lagt i cache.

Jeg legede med nogle koncepter omkring årtusindeskiftet, hvor data ligger zippet (bortset fra png,jpg osv).
På dene måde kan man servere data råt, hvis browseren understøttet gzip, hvilket selv IE understøtter nu om dage.
Google,Yahoo m fl. understøtter også gzip.

Pointen er så, at kun i de tilfælde hvor 'browseren' ikke forstår gzip, så unzippes un-the-fly.

Bortset fra det formentlig kun er bot'er, der ikke forstår gzip, så er det noget mindre belastende at unzippe frem for at zippe.

Jeg havde også understøttelse af deflate (som jo bare er gzip uden headere), med det har jeg droppet, da jeg ikke har kunnet finde nogle browsere, der kun underestøtter defalte.

IE4.x eller IE5.x var vist den sidste.

Selv Lynx understøtter gzip.

Re: Re: Re: Re: Re: Re: Re: Debug i drift?

Har du overvejet (eller måske allerede implementeret) at 'forzippe' data ?

Varnish supporeterer allerede at skelne imellem gzip og ikke komprimeret indhold, forudsat backend-serveren bruger "Vary:" headeren korrekt.

Poul-Henning

Speed up was Debug

Siderne her kan nemt optimeres se eks.
http://code.google.com/speed/a...les/

Re: Speed up was Debug

Siderne her kan nemt optimeres se eks.
http://code.google.com/speed/a...ote>
Her er data fra min Chrome browser

Documents 621mS
Stylesheetes 107ms
Images 225ms
Scripts 326ms
Other 175 ms

En total tid på 1.56s !

Re: Re: Speed up was Debug

Her er data fra min Chrome browser

Documents 621mS
Stylesheetes 107ms
Images 225ms
Scripts 326ms
Other 175 ms

Jep, noget caching ville bestemt hjælp, så databasen ikke skal involveres hele tiden.

Se f.eks:

http://perbu.livejournal.com/6...html

Poul-Henning

Re: Re: Re: Re: Re: Re: Re: Re: Debug i drift?

Varnish supporeterer allerede at skelne imellem gzip og ikke komprimeret indhold

Nu Googlede jeg lige, og det ser ud som du må få opdateret:
http://www.mediawiki.org/wiki/...nish

While Varnish itself performs no compression

Hvilket jeg opfatter som om data ikke bliver 'forzippet'.

Re: Re: Re: Re: Re: Re: Re: Re: Re: Debug i drift?

Varnish supporeterer allerede at skelne imellem gzip og ikke komprimeret indhold

Nu Googlede jeg lige, og det ser ud som du må få opdateret:
http://www.mediawiki.org/wiki/...nish

While Varnish itself performs no compression

Hvilket jeg opfatter som om data ikke bliver 'forzippet'.

Varnish gzip'er ikke (pt), men den kan finde ud af at backend'en gør det.

Poul-Henning

Re: Speed up was Debug

Siderne her kan nemt optimeres se eks.
http://code.google.com/speed/a...ote>
Her er det nok værd at bemærke, at brugen af disse monster javascript 'frameworks' betyder degenereret brug/performance på ældre maskiner/browsere.

Jeg tænker bla. på 'prototype', som lige skal omkonfigurere DOM'en inden visning.

Heldigvis virker siderne langt bedre uden javascript enabled, hvilket jeg generelt kører med, så det er ikke noget problem, men man går nok glip af noget statistik eller lign.