Optimering av websider

[kilogram]

Optimering av websider

Når man lager nettsider, ender man av og til opp med sider som tar lang tid å laste. Her er noen tips for hvordan du kan unngå slike ting.

 

Les artikkelen her

[kristwa]

Fin artikkel, en del nyttige tips å ta med seg for andre programmeringsspråk også. Optimiserte hjemmesiden for en stund siden ved å trimme MySQL spørringene, og siden ble merkbart raskere

[Ernie]

Flott artikkel som mange vil ha svært god nytte av. En ting som jeg umiddelbart mener burde vært med er en liten notis om at INSERT DELAYED bare fungerer på MyISAM, MEMORY og ARCHIVE tabeller. Dvs. at man ikke kan bruke det hvis man har tabeller av typen InnoDB.

 

En ting man også kan merke seg er at man kan tjene mye på god databasedesign, og da spesielt ved høy trafikk/bruk. F.eks kan man i visse situasjoner tjene mye på å bruke datatyper med fast størrelse (char, int o.l) i stedet for datatyper med variabel størrelse (varchar, text, blob o.l). Har man bare faste størrelse i en tabell kan man låse en rad i stedet for hele tabellen når man skal gjøre endringer (INSERT, DELETE og UPDATE). Dette tjener man åpenbart på siden man kan kjøre SELECT samtidig som man endrer noe i samme tabell. I tillegg unngår man overhead. Dog, her må man veie opp tap ytelse mot mer diskbruk.

Endret 21. mars 2006 av Ernie

[efikkan]

Dette er en bra artikkel. Mer slikt vil være bra!

 

Hilsen,

efikkan.

[Ueland]

Flott artikkel som mange vil ha svært god nytte av. En ting som jeg umiddelbart mener burde vært med er en liten notis om at INSERT DELAYED bare fungerer på MyISAM, MEMORY og ARCHIVE tabeller. Dvs. at man ikke kan bruke det hvis man har tabeller av typen InnoDB.

 

En ting man også kan merke seg er at man kan tjene mye på god databasedesign, og da spesielt ved høy trafikk/bruk. F.eks kan man i visse situasjoner tjene mye på å bruke datatyper med fast størrelse (char, int o.l) i stedet for datatyper med variabel størrelse (varchar, text, blob o.l). Har man bare faste størrelse i en tabell kan man låse en rad i stedet for hele tabellen når man skal gjøre endringer (INSERT, DELETE og UPDATE). Dette tjener man åpenbart på siden man kan kjøre SELECT samtidig som man endrer noe i samme tabell. I tillegg unngår man overhead. Dog, her må man veie opp tap ytelse mot mer diskbruk.

5787581[/snapback]

MyISAM støtter ikke låsing på radnivå, kun på tabellnivå, ei heller er varchar særlig mer variabel i forhold til int, siden du på begge setter størrelsen på de.

 

http://www.developer.com/db/article.php/2235521

 

Per dags dato så har jeg fremdeles ikke sett noe some raskere enn lagring av f.eks spørringsresultater på fil, siden de ikke krever all slags oppslag i indekser etc, og ikke minst blir de lagt i minne når de leses ofte nok. (0.000x sekunder er ikke uvanlig lastetid på en fil av grei størrelse)

 

Når det gjelder SELECT * på spørringer så er det litt fy, siden man ikke skal hente ut mer enn de feltene man trenger, for å spare både jobb og båndbredde.

 

Ulempen med Insert delayed igjen er hvis det blir mange nok av de, så får serveren mye å gjøre, og antallet aktive prosesser kan da fort fli i taket hvis tabellen det skal skrives til er låst.

 

Absolutt alt har sine fordeler og ulemper uansett hvordan man vrir og vender på det

[Codename_Paragon]

Temaet er interessant, men jeg føler at dette var mer PHP-fokusert enn hva artikkeltittelen antydet. Det er en god del generelle forbedringsmuligheter jeg også ser kan menytter på HW-systemet.

 

kompresjon: Artikkelen snakker om caching, men om en i tillegg gzip-komprimerer, sparer en ytterligere båndbredde

 

ryddig HTML: en rask sjekk av HTMLkoden viser her mye kommentarer og mange blanke linjer. Disse bør ikke være med i produksjonkode annet enn for test/debug. Om mulig bør en ha lange linjer, vær spesielt obs på HTML fra DocBook, de er finhakket i en smal remse som koster mye i CRLF.

 

grafikk: en rask sjekk her viser at det kan brukes mye PGN istedet for GIF der disse ikke er animerte. En liten test viser også at GIFoptimalisering også sparer stor plass.

 

oppdelig statisk/ikkestatisk: det finnes egne webservere som er langt mer effektive enn generelle servere der innholdet er statisk (typisk bilder/knapper/lyd osv.) Dette kan kjøres på egen server for lastfordeling. Store systemer som IMDB gjør dette. Pass på at en velger fornuftige navn som i.imdb.com og ikke staticmultimediastuffthatiscool.imdb.com. Interessant nok ser jeg at HW gjør dette delvis.

 

korte URLer: bruk https://www.diskusjon.no/sd/inv_biggrin.gif istedetfor https://www.diskusjon.no/style_emoticons/default/inv_biggrin.gif (dette må en tenke på ved oppsett, senere er det upraktisk å endre).

[stiber]

Fin guide, men jeg vil legge til en ting. Dette gjelder count() i for sløyfene.

 

Vær oppmerksom på at count() i en for sløyfe kjøres for hver gjennomgang av sløyfen. Og dess lengre array enn har jo større blir problemet. Ikke bare kjøres sløyfen N ganger. Arrayen blir telt opp like mange ganger.

 

Hvis man er sikker på at arrayen ikke endrer lengde mens for sløyfen kjører, så tell array på forhånd.

<?php
$array = range(0,1000000);
for($i=0;$i < count($array); $i++) {
//Treg sløfe
}
$array_length = count($array);
for($i=0;$i < $array_length; $i++) {
//Rask sløyfe
}
?>

Jeg har en kode som konverterer kartdata fra SOSI til SVG, hvor arrays med tusenvis av kurver, flater og punkter går gjennom mange, lange og av og til nestede for sløyfer. Denne konverteringsprosessen tar lang tid (opptil 20 minutter), og blir bare kjørt en gang for hvert kart. Men ved å forhåndstelle arrays, sparer jeg faktisk minutter.

 

Ved mindre apllikasjoner er nok forskjellen heller liten.

[pej]

Temaet er interessant, men jeg føler at dette var mer PHP-fokusert enn hva artikkeltittelen antydet. Det er en god del generelle forbedringsmuligheter jeg også ser kan menytter på HW-systemet.

Du trekker fram HW-nettverket som eksempel, så jeg vil gjerne utdype litt.

 

ryddig HTML: en rask sjekk av HTMLkoden viser her mye kommentarer og mange blanke linjer. Disse bør ikke være med i produksjonkode annet enn for test/debug. Om mulig bør en ha lange linjer, vær spesielt obs på HTML fra DocBook, de er finhakket i en smal remse som koster mye i CRLF.

Først og fremst, jeg mener (strategisk plasserte) blanke linjer gir langt mer lesbar og ryddigere HTML-kode, og jeg ser heller ikke optimaliseringsverdien med å fjerne disse?

 

Når det gjelder bruk av kommentarer, så er de aller fleste av disse generert av annonsesystemet. Det er sikkert noen tilfeller hvor utvikleren har lagt til kommentarer selv, men dette er ofte god kodeskikk i utviklingsmiljøer hvor man jobber flere sammen om koden (noe vi gjør i HW). Dette for å informere om hvilken div-tagg som avsluttes o.l. Jeg er dog enig i at bruken av disse bør begrenses så mye som overhodet mulig. Vi skriver f.eks ikke:

 

<div class="foo">
   <p>bar</p>
</div> <!-- end div.foo -->

Men hvis disse blir benyttet ved større wrappere og containere hvor det er umulig å se start/slutt umiddelbart, så er de praktiske.

 

oppdelig statisk/ikkestatisk: det finnes egne webservere som er langt mer effektive enn generelle servere der innholdet er statisk (typisk bilder/knapper/lyd osv.) Dette kan kjøres på egen server for lastfordeling. Store systemer som IMDB gjør dette. Pass på at en velger fornuftige navn som i.imdb.com og ikke staticmultimediastuffthatiscool.imdb.com. Interessant nok ser jeg at HW gjør dette delvis.

HW bruker bilder.hardware.no (delvis images.gfx.no også) for bilder, mens vi har lagret alt av statisk innhold (CSS, grafikk) for forumet på static.diskusjon.no. Hvor er optimaliseringsverdien i å bruke navn som eksempelvis b.hardware.no og s.diskusjon.no, sånn rent bortsett fra de få bytesene man sparer ved lasting av bildeadressen? Jeg mener at fornuftige navn er beskrivende navn. Det er f.eks. ingen tvil om hva bilder.hardware.no blir brukt til, men b.hardware.no? Jeg vet jeg ihvertfall ville stusset litt på hva det var for noe hvis noen bare viste meg den adressen. Endret 25. mars 2006 av apedoktor

[Codename_Paragon]

Temaet er interessant, men jeg føler at dette var mer PHP-fokusert enn hva artikkeltittelen antydet. Det er en god del generelle forbedringsmuligheter jeg også ser kan menytter på HW-systemet.

Du trekker fram HW-nettverket som eksempel, så jeg vil gjerne utdype litt.

Det setter jeg pris på, det er interessant å se litt mer om hvordan ting fungerer i kulissene.

ryddig HTML: en rask sjekk av HTMLkoden viser her mye kommentarer og mange blanke linjer. Disse bør ikke være med i produksjonkode annet enn for test/debug. Om mulig bør en ha lange linjer, vær spesielt obs på HTML fra DocBook, de er finhakket i en smal remse som koster mye i CRLF.

Først og fremst, jeg mener (strategisk plasserte) blanke linjer gir langt mer lesbar og ryddigere HTML-kode, og jeg ser heller ikke optimaliseringsverdien med å fjerne disse?

Det er ingen tvil om at det er lettere å lese, det jeg refererte til var produksjonskoden. Jeg regner med at mye er automatisert og at lite endre for hånd i hver artikkel, eller tar jeg feil?

Når det gjelder bruk av kommentarer, så er de aller fleste av disse generert av annonsesystemet. Det er sikkert noen tilfeller hvor utvikleren har lagt til kommentarer selv, men dette er ofte god kodeskikk i utviklingsmiljøer hvor man jobber flere sammen om koden (noe vi gjør i HW). Dette for å informere om hvilken div-tagg som avsluttes o.l. Jeg er dog enig i at bruken av disse bør begrenses så mye som overhodet mulig. Vi skriver f.eks ikke:

 

<div class="foo">
   <p>bar</p>
</div> <!-- end div.foo -->

Men hvis disse blir benyttet ved større wrappere og containere hvor det er umulig å se start/slutt umiddelbart, så er de praktiske.

Dersom en ser feil i systemet burde det bare være å gå tilbake til den uoptimaliserte HTML-koden. Optimaliseringen skal gi samme rendering i weblesere, ellers er det ingen vits i dem.

oppdelig statisk/ikkestatisk: det finnes egne webservere som er langt mer effektive enn generelle servere der innholdet er statisk (typisk bilder/knapper/lyd osv.) Dette kan kjøres på egen server for lastfordeling. Store systemer som IMDB gjør dette. Pass på at en velger fornuftige navn som i.imdb.com og ikke staticmultimediastuffthatiscool.imdb.com. Interessant nok ser jeg at HW gjør dette delvis.

HW bruker bilder.hardware.no (delvis images.gfx.no også) for bilder, mens vi har lagret alt av statisk innhold (CSS, grafikk) for forumet på static.diskusjon.no. Hvor er optimaliseringsverdien i å bruke navn som eksempelvis b.hardware.no og s.diskusjon.no, sånn rent bortsett fra de få bytesene man sparer ved lasting av bildeadressen? Jeg mener at fornuftige navn er beskrivende navn. Det er f.eks. ingen tvil om hva bilder.hardware.no blir brukt til, men b.hardware.no? Jeg vet jeg ihvertfall ville stusset litt på hva det var for noe hvis noen bare viste meg den adressen.

5808459[/snapback]

Det er som du sier en optimalisering. Det kan nok virke trivielt, men når en summerer opp alt sammen, så blir det endel tilslutt, både i besparelser i båndbredde såvel som i nedlastningstid hos brukere. Bruker en gzip på HTML-koden blir det da CPUbesparelser der også

 

For moro skyld kjørte jeg hw.no gjennom analysatoren til Optiview, som hevder en der kan spare 36 prosent. For diskusjon.no ble det 14- 36 prosent. Riktignok har de da et produkt de gjerne vil selge.

 

Jeg trodde jeg så noe om PNG her, men ser det ikke lengre. Som en liten test tok jeg å lastet ned 12 knappebilder i GIF og optimaliserte med gifsicle -b -O2 *.gif, og reduserte størrelsen fra 17 KB til 13 KB.

 

HW.no operer kommersielt, så jeg er nysgjerrig på hvor mye besparelse som må til før kost/nytteforholdet gjør det lønnsomt. Slashdot kjørte uoptimalisert i mange år før de la om, så jeg er fullt ut klar over at regnskapet ikke er trivielt.

[8086]

mulig en kuriositet, men man kan lett regne ut det n-te fibonaccitallet direkte. altså en metode som er langt raskere enn noen av de som hittil er presentert:

http://www.mcs.surrey.ac.uk/Personal/R.Kno...la.html#formula

Formelen er også presentert i de fleste lineær algebra-bøker for førsteårsstudenter.

 

Om jeg skulle ha et poeng måtte det vel være at ren matematikk kan gi raskere programmer i enkelte tilfeller. Fibonaccitall dukker opp i flere sammenhenger der slikt kan være interessant...

[kilogram]

mulig en kuriositet, men man kan lett regne ut det n-te fibonaccitallet direkte. altså en metode som er langt raskere enn noen av de som hittil er presentert:

http://www.mcs.surrey.ac.uk/Personal/R.Kno...la.html#formula

Formelen er også presentert i de fleste lineær algebra-bøker for førsteårsstudenter.

 

Om jeg skulle ha et poeng måtte det vel være at ren matematikk kan gi raskere programmer i enkelte tilfeller. Fibonaccitall dukker opp i flere sammenhenger der slikt kan være interessant...

6107501[/snapback]

 

Den burde eg ha vore klar over/komt på, og den burde vore nevnt som ein avslutningskommentar i artikkelen. Uansett, Fibonacci-talla er eit veldig klassisk eksempel å bruke når det er snakk om optimering av kode, så det som står i artikkelen er fremdeles gyldig.

 

mvh.,

Vegard