mboost-dp1
newz.dk
Min erfaring er, at sider indlæses meget hurtigere med Adblock Plus slået til - til gengæld vil jeg også gerne være med til at (lade som om at jeg) betaler for siderne, så Adblock Plus er sjældent slået til.
Jeg har så indgået et kompromis med mig selv og indstillet Flash til click-to-play. Siderne indlæses væsentligt hurtigere, og jeg "betaler" for brug.
Jeg har så indgået et kompromis med mig selv og indstillet Flash til click-to-play. Siderne indlæses væsentligt hurtigere, og jeg "betaler" for brug.
#1
Det kan ogsaa klart hjaelpe at slaa 3rd party scripting fra :)
Fx paa newz.dk har deres uendeligt mange "Addthis" links for FAcebook og Twitter tilfoejet over 2 sekunder i load-time paa forsiden :D
Og de blev saa ikke cached, hvilket kun goer ondt vaerre :D
Men der er rigtigt mange der laver den slags third-party crap, selvom det ville tage 2 sekunder at fikse et normalt link :D
Det kan ogsaa klart hjaelpe at slaa 3rd party scripting fra :)
Fx paa newz.dk har deres uendeligt mange "Addthis" links for FAcebook og Twitter tilfoejet over 2 sekunder i load-time paa forsiden :D
Og de blev saa ikke cached, hvilket kun goer ondt vaerre :D
Men der er rigtigt mange der laver den slags third-party crap, selvom det ville tage 2 sekunder at fikse et normalt link :D
Det er tit og ofte fordi de der sider og laver sideren ikke kan andet end at kode, de kan ikke finde ud af at perfome serveren, optimere databasen og minimere javascript + css style, sider selv som udvikler.
arbejder med omkring 25 javascript filer + forskellige frameworks, når lave en .min.js fil ud af det fylder det 1 og browseren vi har i dag med HTTP 1.1 standarten tillader kun 2-3 paralle downlaods og det er her problemet ofte opstår.
så et hurtig tip til de der sider og laver hjemmesider der ude gør følgenen.
1) Lav dine CSS filer i LESS for at få OOP CSS så meget som muligt, minmere dem efterfulgt så kommenter m.m. fjernes., indlæs din CSS i din i mellem dine "head" tags
2) sammel alle dine JS filer i 1 fil, bruger i jQuery beholder du den stadig i en fil, men sør for at det hele er minimere smid dine 2 js filer i bunden af siden ( jQuery først )
3) hvis du har en masse ting der loader på din side, så lad det ske efter brugeren har hentet dit indhold, hvor efter de kan få deres "ikke søgebar indhold" at se, det spare ufaligt meget load tid.
4) til sidst, husk at både google analytic, banner tags og hvad der ellers hentes extern fra hent det ALTID til sidst, har gjort det på et stort sit og vi sparet omkring 10-15 seci load tid, og så lader den bare brugeren se en "box" uden indhold ind til den har hentet det, :) banner generalt er total killer og som #1 siger, AdBlock plus er en god ting for slut brugeren at bruge for at perfome deres browser ;)
Hvis du er mere teknisk anlagt udvikler og har styr på din webserver, så husk at gzip dit indhold ( hvis du koder PHP ) ved ik hvad det hedder i andre sprog ^^ vær sikker på din Apache cache indhold så som JS, CSS og billedere, slå dit cache fra i din egen browser når du udvikler så undgår du trælse bugs som du tror der er men aligevel ikke er der på grund af javascripten eks.
Kan du MySQL så kør InnoDB samt cache dine str. i rammene, resefvere 70% af dine ram på din MySQL server til et cache så som InnoDB, MyISAM tables, querys og inner joins
alene der spares du utorligt meget tid, :) er du hoste hos eks. one.com og andre udbyder er du fuckt, bruger du wordpress, er der også kæmpe perfomes issues her ;) håber dette giver dig løsten til at udvikle alt selv og få mere styr på din egen webserver, virtuale server kan fås for omkring 100 - 200kr pr mdr ;) og man kan lave og perfome langt mere selv om en server ligge i USA kan man få svar tiden værlset ned.
og til allersidst, hvis alle overståne er på palds, så fix en CDN eller gennem gå din kilde kode ;) newrelic.com er god for til at overvåge din server og fortælle hviklen scripts der virklig smader serveren samt DB querys. virklig et brugbart værktøj! :D
arbejder med omkring 25 javascript filer + forskellige frameworks, når lave en .min.js fil ud af det fylder det 1 og browseren vi har i dag med HTTP 1.1 standarten tillader kun 2-3 paralle downlaods og det er her problemet ofte opstår.
så et hurtig tip til de der sider og laver hjemmesider der ude gør følgenen.
1) Lav dine CSS filer i LESS for at få OOP CSS så meget som muligt, minmere dem efterfulgt så kommenter m.m. fjernes., indlæs din CSS i din i mellem dine "head" tags
2) sammel alle dine JS filer i 1 fil, bruger i jQuery beholder du den stadig i en fil, men sør for at det hele er minimere smid dine 2 js filer i bunden af siden ( jQuery først )
3) hvis du har en masse ting der loader på din side, så lad det ske efter brugeren har hentet dit indhold, hvor efter de kan få deres "ikke søgebar indhold" at se, det spare ufaligt meget load tid.
4) til sidst, husk at både google analytic, banner tags og hvad der ellers hentes extern fra hent det ALTID til sidst, har gjort det på et stort sit og vi sparet omkring 10-15 seci load tid, og så lader den bare brugeren se en "box" uden indhold ind til den har hentet det, :) banner generalt er total killer og som #1 siger, AdBlock plus er en god ting for slut brugeren at bruge for at perfome deres browser ;)
Hvis du er mere teknisk anlagt udvikler og har styr på din webserver, så husk at gzip dit indhold ( hvis du koder PHP ) ved ik hvad det hedder i andre sprog ^^ vær sikker på din Apache cache indhold så som JS, CSS og billedere, slå dit cache fra i din egen browser når du udvikler så undgår du trælse bugs som du tror der er men aligevel ikke er der på grund af javascripten eks.
Kan du MySQL så kør InnoDB samt cache dine str. i rammene, resefvere 70% af dine ram på din MySQL server til et cache så som InnoDB, MyISAM tables, querys og inner joins
alene der spares du utorligt meget tid, :) er du hoste hos eks. one.com og andre udbyder er du fuckt, bruger du wordpress, er der også kæmpe perfomes issues her ;) håber dette giver dig løsten til at udvikle alt selv og få mere styr på din egen webserver, virtuale server kan fås for omkring 100 - 200kr pr mdr ;) og man kan lave og perfome langt mere selv om en server ligge i USA kan man få svar tiden værlset ned.
og til allersidst, hvis alle overståne er på palds, så fix en CDN eller gennem gå din kilde kode ;) newrelic.com er god for til at overvåge din server og fortælle hviklen scripts der virklig smader serveren samt DB querys. virklig et brugbart værktøj! :D
Da jeg hverken er på Facebook, Twitter eller nogen som helst anden social medie, måtte de gerne droppe "sociale" links.
Og jeg kan total bakke om omkring at tracking scripts er et problem... Synes jeg meget ofte oplever en "venter på trackingfirma.com" i min statusbar, når jeg loader en side.
Og jeg kan total bakke om omkring at tracking scripts er et problem... Synes jeg meget ofte oplever en "venter på trackingfirma.com" i min statusbar, når jeg loader en side.
#4 De sider der kører langsomt, gør det ofte fordi serverne og selve websitet er sat dårligt op.
Slevfølgelig kan man lave elendig kode, men det er ting som ordentlig caching der virkelig betyder noget i helheden. Ordentlig brug af browser cache er meget vigtigt og ofte ikke sat ordentligt op på danske sider.
#5 Så fordi du er en social analfabet på nettet, så skal alle websites rette ind efter dig?
Slevfølgelig kan man lave elendig kode, men det er ting som ordentlig caching der virkelig betyder noget i helheden. Ordentlig brug af browser cache er meget vigtigt og ofte ikke sat ordentligt op på danske sider.
#5 Så fordi du er en social analfabet på nettet, så skal alle websites rette ind efter dig?
#4
Egentligt korrekt, men det vidner langt mere om, at folk ikke kan finde ud af at bygge deres sider op korrekt.
Og specielt folk der bruger frameworks loader uendeligt meget bras ind, for at vise en "Hello World" ... :D
De fleste bruger et CDN i dag, netop af den aarsag, men det kan rent faktisk ogsaa tweakes i ens apache konfiguration, fx.
Det kan ogsaa godt svare sig fx at kigge paa Piwik som alternativ til GA, da det kan hostes selv og du derved ikke skal ud til tredjepart :)
Gzip hjaelper ikke paa at du har for mange download streams, det er kun hvis din kode fylder ekstremt meget - hvilket den ikke boer anyway :D
Et godt tip er ogsaa, at en CDN kan koere paa samme server og derved omgaar du HTTP1.1 begraensningen, selvom du stadig kun har 1 host.
(Saafremt du bruger flere subdomains) :)
Men super post ellers :D
Det er tit og ofte fordi de der sider og laver sideren ikke kan andet end at kode, de kan ikke finde ud af at perfome serveren, optimere databasen og minimere javascript + css style, sider selv som udvikler.
Egentligt korrekt, men det vidner langt mere om, at folk ikke kan finde ud af at bygge deres sider op korrekt.
Og specielt folk der bruger frameworks loader uendeligt meget bras ind, for at vise en "Hello World" ... :D
arbejder med omkring 25 javascript filer + forskellige frameworks, når lave en .min.js fil ud af det fylder det 1 og browseren vi har i dag med HTTP 1.1 standarten tillader kun 2-3 paralle downlaods og det er her problemet ofte opstår.
De fleste bruger et CDN i dag, netop af den aarsag, men det kan rent faktisk ogsaa tweakes i ens apache konfiguration, fx.
4) til sidst, husk at både google analytic, banner tags og hvad der ellers hentes extern fra hent det ALTID til sidst
Det kan ogsaa godt svare sig fx at kigge paa Piwik som alternativ til GA, da det kan hostes selv og du derved ikke skal ud til tredjepart :)
Hvis du er mere teknisk anlagt udvikler og har styr på din webserver, så husk at gzip dit indhold ( hvis du koder PHP ) ved ik hvad det hedder i andre sprog ^^
Gzip hjaelper ikke paa at du har for mange download streams, det er kun hvis din kode fylder ekstremt meget - hvilket den ikke boer anyway :D
så fix en CDN
Et godt tip er ogsaa, at en CDN kan koere paa samme server og derved omgaar du HTTP1.1 begraensningen, selvom du stadig kun har 1 host.
(Saafremt du bruger flere subdomains) :)
Men super post ellers :D
#6
I beg to differ.
En standard Apache konfig koerer ganske glimrende.
Kan du komme med et eksempel paa hvad "ordentligt caching" er?
Hmm.. Apache har vist en standard tid som kan konfigureres ved forskellige billedtyper, etc.
Men ja, det kan ofte godt svare sig hvis man loader mange tunge billeder ind, fx, at saette en laengere udloebstid paa dem - men det goer man jo ret sjaeldent, medmindre man har et specifikt formaal i at vise high-res billeder, fx :)
De sider der kører langsomt, gør det ofte fordi serverne og selve websitet er sat dårligt op.
I beg to differ.
En standard Apache konfig koerer ganske glimrende.
Slevfølgelig kan man lave elendig kode, men det er ting som ordentlig caching der virkelig betyder noget i helheden.
Kan du komme med et eksempel paa hvad "ordentligt caching" er?
Ordentlig brug af browser cache er meget vigtigt og ofte ikke sat ordentligt op på danske sider.
Hmm.. Apache har vist en standard tid som kan konfigureres ved forskellige billedtyper, etc.
Men ja, det kan ofte godt svare sig hvis man loader mange tunge billeder ind, fx, at saette en laengere udloebstid paa dem - men det goer man jo ret sjaeldent, medmindre man har et specifikt formaal i at vise high-res billeder, fx :)
F.eks. bruger Newz.dk ikke browser cache ordentligt, eller regler for browser cache er ikke opsat på en hel del filer:
http://tools.pingdom.com/fpt/#!/OS2eAyYML/http://n...
Selv om indhold er dynamisk, så kan man sagtens f.eks. opsætte en 2 minutters expire. Det gør ikke første load hurtigere direkte, men fordi serveren ikke skal sende ALT indhold forfra til de tosser der sidder og trykker F5 hvert 3. sekund, så fjerner den vej igennem belastning af serveren.
Mange IIS servere bruger heller ikke database håndterede sessions. Det betyder i realiteten at selv om de har 64 kerner og 100GB ram. SSD diske osv. Så kan hver app pool stadig kun håndtere 1 request ad gangen.
http://tools.pingdom.com/fpt/#!/OS2eAyYML/http://n...
Selv om indhold er dynamisk, så kan man sagtens f.eks. opsætte en 2 minutters expire. Det gør ikke første load hurtigere direkte, men fordi serveren ikke skal sende ALT indhold forfra til de tosser der sidder og trykker F5 hvert 3. sekund, så fjerner den vej igennem belastning af serveren.
Mange IIS servere bruger heller ikke database håndterede sessions. Det betyder i realiteten at selv om de har 64 kerner og 100GB ram. SSD diske osv. Så kan hver app pool stadig kun håndtere 1 request ad gangen.
#13) Arh, eks. der hvor jeg arbejder har de 100.000 unikke besøge pr mdr, setuppet er blot 4-core, 8gb ram på en linux maskine hvor der er teaket helt vildt i Apache + MySQL samt omskrevet en del kode så som javascript + css og minmere det, så Varnish bør ikke være et krav, dog vil jeg nok anbefalde Varnish hvis der er tale om et SaaS produkt hvor der er en masse bruger der smider content op og der der ved bliver hentet mange filer den vej, men på normale omstændigere bør det ikke være et problem så er jeg enig med #12 at så ska man stoppe slam kode ^^
Interessant debat herinde .. den mest interessante jeg længer har set .. :D ..
Nu arbejder jeg selv med websites i det daglige, og har dagligt udfordringer mht. optimering - vil sige at det ikke KUN gælder om at have god caching, eller KUN om at minify og samle ens CSS og JS filer, eller KUN om at have en god server ...
Det er kombinationen af alle de metoder der findes til at optimere .. ISÆR når der køres globale websites med flere millioner hits per måned .. På et website der kun kører dansk, med relativt få hits per måned, der er det jo næsten ligemeget .. Men jo større det bliver - jo flere ting skal man huske at have med nærmest ...
Dvs. Server struktur, page caching, minified css og js, samlet css og js i 1 fil hver, minimeret antallet af HTTP request, brug af CDN, brug af sprites i css, ordentlig side struktur, og så selvf. kun tage det med der er behov for på hver side - bare for at nævne nogle af de mest gængse ..
Nu arbejder jeg selv med websites i det daglige, og har dagligt udfordringer mht. optimering - vil sige at det ikke KUN gælder om at have god caching, eller KUN om at minify og samle ens CSS og JS filer, eller KUN om at have en god server ...
Det er kombinationen af alle de metoder der findes til at optimere .. ISÆR når der køres globale websites med flere millioner hits per måned .. På et website der kun kører dansk, med relativt få hits per måned, der er det jo næsten ligemeget .. Men jo større det bliver - jo flere ting skal man huske at have med nærmest ...
Dvs. Server struktur, page caching, minified css og js, samlet css og js i 1 fil hver, minimeret antallet af HTTP request, brug af CDN, brug af sprites i css, ordentlig side struktur, og så selvf. kun tage det med der er behov for på hver side - bare for at nævne nogle af de mest gængse ..
NeoNmaN (16) skrev:#14) 2min? hvorfor ikke bare cache alle artikler som er de 1000 mest læste i rammene ^^ samt loade kommenter til sidst XD det vil også spare deres server vold meget ^^ er mit gæt! :D
Fordi 2 min. expire stadig er meget nemt at sætte op i forhold til at kode sin egen cache løsning. Derfor er der ingen undskyldning for ikke at bruge det.
Som hovedregel skal man slet ikke levere et http resultat uden en expire i headeren. Heller ikke selv om den skulle være 0. Det tvinger både en selv til at tage stilling til levetiden af de informationer man sender ud, og giver bedre performance fir brugerne. Det er med andre ord en win-win situation :)
Hvis man bruger WordPress kan jeg varmt anbefale et plugin, der hedder W3 Cache.
#16
Alle aktive requests er allerede cachet i rammen, btw.
Comments er text-only og fylder, i vaerste fald, 10kB. Og saa har man SERIOEST mange comments.
Dvs at man loader 10kB comments ind paa ~0.1 sekund. Not going to make a difference.
I saa fald skulle det vaere ens SQL som skal optimeres.
2min? hvorfor ikke bare cache alle artikler som er de 1000 mest læste i rammene ^^
Alle aktive requests er allerede cachet i rammen, btw.
samt loade kommenter til sidst XD det vil også spare deres server vold meget ^^ er mit gæt! :D
Comments er text-only og fylder, i vaerste fald, 10kB. Og saa har man SERIOEST mange comments.
Dvs at man loader 10kB comments ind paa ~0.1 sekund. Not going to make a difference.
I saa fald skulle det vaere ens SQL som skal optimeres.
#20) ja men du kan have nok så lidt tekst, skal du vise det til brugeren med det samme isted for et dilay på eks. 1sec eller 0.5sec alt efter hvornår ens browser loader siden done, så vil det her også være mildere forserveren at skifte fra side til side da en realt set bare ska læse nyt JSON isted for at skal lave et fysisk side request.
godt være du tror det er det samme men det er det ikke, :) du kan selv lave testen hvor du har 100k. rows, og det ene udtræk laver du med 25-50 pr side skifte fra side til side frem og tilbage, gør nu det samme med et jQuery pages skift, hvor du bruger JSON til at bygge alt op, du vil se en gevaldig bruger oplevelse ædring ,der er en grund til Facebook netop bygger alt op efter siden er loadet :)
som regl er alt der med det samme, men skulle der være forsinklere får du stadig "main content" vist så du kan se der sker noget, og rasten sker så når den lige får leveret indholdet.
og hvis der er 25 comments af eks. 5kb pr stk der er 100 bruger online på news der skifter mellem nyhederen og nyhedsoversigten eks. 5 gange så er det altså en bevælse(side visninger) på ialt 12.500, som ca. laver ( 757.5K load ved forsiden ) og ( 540.1K load ) ved en "underside med 15 kommentar" det er altså følge seniere
1) forsiden ( 750kb )
2) underside 1 ( 540.1K )
3) næste side - læs flere kommentar ( 540.1K )
4) næste side - læs flere kommentar ( 540.1K )
5) næste side - læs flere kommentar ( 540.1K )
det vil være over 2,5mb load pr bruger hvis du der imod gjore det med JSON vil du sende netop 25x 5kb data tilbage til browseren og derved spare over 400kb pr side request, det spare altså serveren for utorlig meget load + båndbredte af brugerens side og endag gør det også siden ufaligt hurtig iforholdt til den måde det fungere på i dag på Newz
godt være du tror det er det samme men det er det ikke, :) du kan selv lave testen hvor du har 100k. rows, og det ene udtræk laver du med 25-50 pr side skifte fra side til side frem og tilbage, gør nu det samme med et jQuery pages skift, hvor du bruger JSON til at bygge alt op, du vil se en gevaldig bruger oplevelse ædring ,der er en grund til Facebook netop bygger alt op efter siden er loadet :)
som regl er alt der med det samme, men skulle der være forsinklere får du stadig "main content" vist så du kan se der sker noget, og rasten sker så når den lige får leveret indholdet.
og hvis der er 25 comments af eks. 5kb pr stk der er 100 bruger online på news der skifter mellem nyhederen og nyhedsoversigten eks. 5 gange så er det altså en bevælse(side visninger) på ialt 12.500, som ca. laver ( 757.5K load ved forsiden ) og ( 540.1K load ) ved en "underside med 15 kommentar" det er altså følge seniere
1) forsiden ( 750kb )
2) underside 1 ( 540.1K )
3) næste side - læs flere kommentar ( 540.1K )
4) næste side - læs flere kommentar ( 540.1K )
5) næste side - læs flere kommentar ( 540.1K )
det vil være over 2,5mb load pr bruger hvis du der imod gjore det med JSON vil du sende netop 25x 5kb data tilbage til browseren og derved spare over 400kb pr side request, det spare altså serveren for utorlig meget load + båndbredte af brugerens side og endag gør det også siden ufaligt hurtig iforholdt til den måde det fungere på i dag på Newz
#21
Det der giver ikke mening.
Du vil loade JSON fra en anden side, for at sitet loader hurtigt men kommentarer loader langsomt?
Du kan bare bruge fx Jquery til at saette dine kommentarer ind fx.
Hvis du har 100.000 kommentarer til en nyhed, saa skal du alligevel have noget serioes paginering :)
Jow, det er bare meget sjaeldent noedvendigt at goere saa meget ud af det.
5kB?! Wtf er det for noget data du vil loade ind? :D
What?
Det vil vaere 1 pageload pr side pr user.
Hvis du mener fil-load, saa vil det vaere 5-x. Index, subpage, SQL, JS og CSS.
JS og CSS er cached, fx, saa det er nok et mindre problem.
Men 12.500? Dvs du har 125 sidelaesninger for at loade en side?
Jeg er slet ikke med paa din udregning her :)
Du kan ogsaa bare lade vaere med at loade alle 100.000.000 comments ind paa forsiden, naar du alligevel vil lave paginering.
Saa skal du kun loade 5 kommentarer = 25kB, hvis man bruger dine 5kB pr kommentar.
I praksis er det utroligt meget mindre, da din data kommer fra SQL og din HTML fylder stort set intet.
ja men du kan have nok så lidt tekst, skal du vise det til brugeren med det samme isted for et dilay på eks. 1sec eller 0.5sec alt efter hvornår ens browser loader siden done, så vil det her også være mildere forserveren at skifte fra side til side da en realt set bare ska læse nyt JSON isted for at skal lave et fysisk side request.
Det der giver ikke mening.
Du vil loade JSON fra en anden side, for at sitet loader hurtigt men kommentarer loader langsomt?
godt være du tror det er det samme men det er det ikke, :)
Du kan bare bruge fx Jquery til at saette dine kommentarer ind fx.
du kan selv lave testen hvor du har 100k. rows,
Hvis du har 100.000 kommentarer til en nyhed, saa skal du alligevel have noget serioes paginering :)
som regl er alt der med det samme, men skulle der være forsinklere får du stadig "main content" vist så du kan se der sker noget, og rasten sker så når den lige får leveret indholdet.
Jow, det er bare meget sjaeldent noedvendigt at goere saa meget ud af det.
og hvis der er 25 comments af eks. 5kb pr stk
5kB?! Wtf er det for noget data du vil loade ind? :D
der er 100 bruger online på news der skifter mellem nyhederen og nyheoversigten eks. 5 gange så er det altså en bevælse(side visninger) på ialt 12.500, som ca. laver ( 757.5K load ved forsiden ) og ( 540.1K load ) ved en "underside med 15 kommentar" det er altså følge seniere
1) forsiden ( 750kb )
2) underside 1 ( 540.1K )
3) næste side - læs flere kommentar ( 540.1K )
4) næste side - læs flere kommentar ( 540.1K )
5) næste side - læs flere kommentar ( 540.1K )
What?
Det vil vaere 1 pageload pr side pr user.
Hvis du mener fil-load, saa vil det vaere 5-x. Index, subpage, SQL, JS og CSS.
JS og CSS er cached, fx, saa det er nok et mindre problem.
Men 12.500? Dvs du har 125 sidelaesninger for at loade en side?
Jeg er slet ikke med paa din udregning her :)
det vil være over 2,5mb load pr bruger hvis du der imod gjore det med JSON vil du sende netop 25x 5kb data tilbage til browseren og derved spare over 400kb pr side request, det spare altså serveren for utorlig meget load + båndbredte af brugerens side og endag gør det også siden ufaligt hurtig iforholdt til den måde det fungere på i dag på Newz
Du kan ogsaa bare lade vaere med at loade alle 100.000.000 comments ind paa forsiden, naar du alligevel vil lave paginering.
Saa skal du kun loade 5 kommentarer = 25kB, hvis man bruger dine 5kB pr kommentar.
I praksis er det utroligt meget mindre, da din data kommer fra SQL og din HTML fylder stort set intet.
#25
hosts er bedre.
På Windows: C:\Windows\System32\drivers\etc\hosts, åben med en teksteditor.
Jeg har tilføjet følgende:
hosts er bedre.
På Windows: C:\Windows\System32\drivers\etc\hosts, åben med en teksteditor.
Jeg har tilføjet følgende:
127.0.0.1 addthis.com
127.0.0.1 *.gemius.pl
127.0.0.1 gemius.pl
127.0.0.1 www.gemius.pl[/code]
Ja, jeg har forsøgt alt hvad jeg kan at undgå Gemius.
#21
Jeg vil helt klart lave et dilay på at når hele siden er hentet ind så startere den først med at loade kommentar, og isted for "side skift" ved eks. 25 kommentar vil jeg klart lave scroll-loading.
Nej nu tænker jeg ikke på 1 nyhed, nu tænker jeg i din database ofc. ^^
Med en vis volumene på dit website, e det en god idé at gøre dele af content-elementeren til "dialy-loading"
Ja, true men der er forskælg på at loade hele siden eller kun X antal kb's i tilfælde af kommentar, kunne også være i andre sammenhæng men her er der bare tale om kommentar til en nyhed.
100 bruger der ser 5 nyheder eller skifter side på ca. 2-3 minutter giver 500 sidevisninger ( min fejl ) tak for rettelsen ;D
Du loader slf. ikke 100m kommentar i et row det er jeg udemærket klar over, men lige meget hvad skal den jo stadig finde dine kommentar + alt andet indhold, så har du en database med eks. 100k kommentar fordelt over på 5k nyheder, så gir det stadig en load + hvis du har en masse andet gejl der bliver loadet rundt på siden.
Ja du kan indexere din DB er jeg også godt klar over, men det er stadig hurtiger at finde eks. de næste 15 kommentar til en nyheds hvis den kun skal finde de næste 15 isted for den skal finde nyheden + kommentar + en masse andet snask som mange sider loader ind!
Det der giver ikke mening.
Du vil loade JSON fra en anden side, for at sitet loader hurtigt men kommentarer loader langsomt?godt være du tror det er det samme men det er det ikke, :)
Jeg vil helt klart lave et dilay på at når hele siden er hentet ind så startere den først med at loade kommentar, og isted for "side skift" ved eks. 25 kommentar vil jeg klart lave scroll-loading.
Du kan bare bruge fx Jquery til at saette dine kommentarer ind fx.du kan selv lave testen hvor du har 100k. rows,
Hvis du har 100.000 kommentarer til en nyhed, saa skal du alligevel have noget serioes paginering :)
Nej nu tænker jeg ikke på 1 nyhed, nu tænker jeg i din database ofc. ^^
som regl er alt der med det samme, men skulle der være forsinklere får du stadig "main content" vist så du kan se der sker noget, og rasten sker så når den lige får leveret indholdet.
Jow, det er bare meget sjaeldent noedvendigt at goere saa meget ud af det.
Med en vis volumene på dit website, e det en god idé at gøre dele af content-elementeren til "dialy-loading"
og hvis der er 25 comments af eks. 5kb pr stk
5kB?! Wtf er det for noget data du vil loade ind? :D
Ja, true men der er forskælg på at loade hele siden eller kun X antal kb's i tilfælde af kommentar, kunne også være i andre sammenhæng men her er der bare tale om kommentar til en nyhed.
der er 100 bruger online på news der skifter mellem nyhederen og nyheoversigten eks. 5 gange så er det altså en bevælse(side visninger) på ialt 12.500, som ca. laver ( 757.5K load ved forsiden ) og ( 540.1K load ) ved en "underside med 15 kommentar" det er altså følge seniere
1) forsiden ( 750kb )
2) underside 1 ( 540.1K )
3) næste side - læs flere kommentar ( 540.1K )
4) næste side - læs flere kommentar ( 540.1K )
5) næste side - læs flere kommentar ( 540.1K )
What?
Det vil vaere 1 pageload pr side pr user.
Hvis du mener fil-load, saa vil det vaere 5-x. Index, subpage, SQL, JS og CSS.
JS og CSS er cached, fx, saa det er nok et mindre problem.
Men 12.500? Dvs du har 125 sidelaesninger for at loade en side?
Jeg er slet ikke med paa din udregning her :)
100 bruger der ser 5 nyheder eller skifter side på ca. 2-3 minutter giver 500 sidevisninger ( min fejl ) tak for rettelsen ;D
det vil være over 2,5mb load pr bruger hvis du der imod gjore det med JSON vil du sende netop 25x 5kb data tilbage til browseren og derved spare over 400kb pr side request, det spare altså serveren for utorlig meget load + båndbredte af brugerens side og endag gør det også siden ufaligt hurtig iforholdt til den måde det fungere på i dag på Newz
Du kan ogsaa bare lade vaere med at loade alle 100.000.000 comments ind paa forsiden, naar du alligevel vil lave paginering.
Saa skal du kun loade 5 kommentarer = 25kB, hvis man bruger dine 5kB pr kommentar.
I praksis er det utroligt meget mindre, da din data kommer fra SQL og din HTML fylder stort set intet.
Du loader slf. ikke 100m kommentar i et row det er jeg udemærket klar over, men lige meget hvad skal den jo stadig finde dine kommentar + alt andet indhold, så har du en database med eks. 100k kommentar fordelt over på 5k nyheder, så gir det stadig en load + hvis du har en masse andet gejl der bliver loadet rundt på siden.
Ja du kan indexere din DB er jeg også godt klar over, men det er stadig hurtiger at finde eks. de næste 15 kommentar til en nyheds hvis den kun skal finde de næste 15 isted for den skal finde nyheden + kommentar + en masse andet snask som mange sider loader ind!
#26
Jeg er uenig.
Jeg har kun blokeret ting fra et givent site, som fx newz.dk.
Jeg har blokeret alt trafik til GA, Facebook, etc, etc, etc, men kun fra newz.dk domaenet ;)
hosts er bedre.
På Windows: C:\Windows\System32\drivers\etc\hosts, åben med en teksteditor.
Jeg har tilføjet følgende:
Jeg er uenig.
Jeg har kun blokeret ting fra et givent site, som fx newz.dk.
Jeg har blokeret alt trafik til GA, Facebook, etc, etc, etc, men kun fra newz.dk domaenet ;)
#27
Men hvorfor have et delay overhovedet?
At loade 25 kommentarer er stort set instant, saa hvis du vil lave paginering, saa er det jo bare replace content med jQuery som alligevel skal ske paa den ene eller anden maade.
Paginering er et must naar man har over 50 comments, imo, og hvis folk ikke vil have paginering, loader man jo bare det hele anyway :)
Ah, well, selv med 100.000 records er svartiden jo 0.0001 sekund.. Problemet ligger mere i hvor meget du man-handler din data foer og efter, da det har en effekt paa hvor meget du kan optimere din SQL :D
Tjoh, i hvilket tilfaelde vil du vente med at loade indhold?
Paa newz.dks forside, fx, kunne man argumentere for at den ikke skal loade alle nyhederne paa en gang (min staar til 50 nyheder), da newz.dk er et ulideligt langsomt website, men ville det ikke vaere langt federe at fikse selve websitet?! :D
Min pointe var mere at en kommentar fylder meget lidt, saa det er nok mere SQL der skal optimeres, eller de kald man laver for at vise kommentaren, end der skal loades med delay ;)
Hehe, men alligevel. 500 sidevisninger er INTET for en korrekt opsat Apache.
Slet ikke hvis det er samme indhold der vises, da den saa cacher en god del af det i hhv. SQL og Apache ;)
Korrekt, men din database er jo korrekt opsat og struktureret, saa til eksempel, saa lavede jeg en test paa vores MS SQL server forleden.
Den er virtualiseret, med 10 andres hosts paa samme boks, ioevrigt.
Den lavede en soegning med 4 joins, i en DB med over 15 mio records, paa ~0.1ms og returnerede mine ~20 hits.
Og det var i produktionstid, dvs vi har 30 saelgere der sidder og spammer data til og fra den ;)
Du skal have et SERIOEST stort load hvis det skal vaere SQL der giver en bottleneck, eller en serioest fubar struktur.
Sandt, men du har jo allerede dit ID og alt din nyhedsdata, saa i princippet vil dit nye kald jo bare vaere en ren SELECT * FROM comments WHERE news_id = '42'; :)
Det tager ikke mange ms at koere, selvom man har en gigantisk DB.
Hvis man endelig vil have mere performance, saa kan man jo strikke en stored procedure sammen og hygge sig med det :)
IMO burde man kun bruge jQuery til at loade ting, hvis man ved at der kan vaere et delay paa. Det boer der aldrig vaere paa dit primaere indhold.
Har du et nyhedssite og skal lave en statik over hvor mange 1000000000 visitors der har gaywanket paa x,y og z tags, med random joins og 3 kilder til data, etc.
Delay load the shit out of it.
Ellers har jeg virkeligt svaert ved at se hvad der skal delay loades, som ikke burde fikses andetsteds istedet ;)
Jeg vil helt klart lave et dilay på at når hele siden er hentet ind så startere den først med at loade kommentar, og isted for "side skift" ved eks. 25 kommentar vil jeg klart lave scroll-loading.
Men hvorfor have et delay overhovedet?
At loade 25 kommentarer er stort set instant, saa hvis du vil lave paginering, saa er det jo bare replace content med jQuery som alligevel skal ske paa den ene eller anden maade.
Paginering er et must naar man har over 50 comments, imo, og hvis folk ikke vil have paginering, loader man jo bare det hele anyway :)
Nej nu tænker jeg ikke på 1 nyhed, nu tænker jeg i din database ofc. ^^
Ah, well, selv med 100.000 records er svartiden jo 0.0001 sekund.. Problemet ligger mere i hvor meget du man-handler din data foer og efter, da det har en effekt paa hvor meget du kan optimere din SQL :D
Med en vis volumene på dit website, e det en god idé at gøre dele af content-elementeren til "dialy-loading"
Tjoh, i hvilket tilfaelde vil du vente med at loade indhold?
Paa newz.dks forside, fx, kunne man argumentere for at den ikke skal loade alle nyhederne paa en gang (min staar til 50 nyheder), da newz.dk er et ulideligt langsomt website, men ville det ikke vaere langt federe at fikse selve websitet?! :D
Ja, true men der er forskælg på at loade hele siden eller kun X antal kb's i tilfælde af kommentar, kunne også være i andre sammenhæng men her er der bare tale om kommentar til en nyhed.
Min pointe var mere at en kommentar fylder meget lidt, saa det er nok mere SQL der skal optimeres, eller de kald man laver for at vise kommentaren, end der skal loades med delay ;)
100 bruger der ser 5 nyheder eller skifter side på ca. 2-3 minutter giver 500 sidevisninger ( min fejl ) tak for rettelsen ;D
Hehe, men alligevel. 500 sidevisninger er INTET for en korrekt opsat Apache.
Slet ikke hvis det er samme indhold der vises, da den saa cacher en god del af det i hhv. SQL og Apache ;)
Du loader slf. ikke 100m kommentar i et row det er jeg udemærket klar over, men lige meget hvad skal den jo stadig finde dine kommentar + alt andet indhold, så har du en database med eks. 100k kommentar fordelt over på 5k nyheder, så gir det stadig en load + hvis du har en masse andet gejl der bliver loadet rundt på siden.
Korrekt, men din database er jo korrekt opsat og struktureret, saa til eksempel, saa lavede jeg en test paa vores MS SQL server forleden.
Den er virtualiseret, med 10 andres hosts paa samme boks, ioevrigt.
Den lavede en soegning med 4 joins, i en DB med over 15 mio records, paa ~0.1ms og returnerede mine ~20 hits.
Og det var i produktionstid, dvs vi har 30 saelgere der sidder og spammer data til og fra den ;)
Du skal have et SERIOEST stort load hvis det skal vaere SQL der giver en bottleneck, eller en serioest fubar struktur.
Ja du kan indexere din DB er jeg også godt klar over, men det er stadig hurtiger at finde eks. de næste 15 kommentar til en nyheds hvis den kun skal finde de næste 15 isted for den skal finde nyheden + kommentar + en masse andet snask som mange sider loader ind!
Sandt, men du har jo allerede dit ID og alt din nyhedsdata, saa i princippet vil dit nye kald jo bare vaere en ren SELECT * FROM comments WHERE news_id = '42'; :)
Det tager ikke mange ms at koere, selvom man har en gigantisk DB.
Hvis man endelig vil have mere performance, saa kan man jo strikke en stored procedure sammen og hygge sig med det :)
IMO burde man kun bruge jQuery til at loade ting, hvis man ved at der kan vaere et delay paa. Det boer der aldrig vaere paa dit primaere indhold.
Har du et nyhedssite og skal lave en statik over hvor mange 1000000000 visitors der har gaywanket paa x,y og z tags, med random joins og 3 kilder til data, etc.
Delay load the shit out of it.
Ellers har jeg virkeligt svaert ved at se hvad der skal delay loades, som ikke burde fikses andetsteds istedet ;)
#4, mig og en kammerat sidder selv og koder en side fra bunden op, med primært New Relic til at fortælle os om tingene vi smider på sløver den alt for meget.
http://zkillboard.com
Stadig massere af ting der skal optimeres, f.eks. css, js og billeder.
Heldigvis så bliver databasen hurtigere af at flere bruger siden, i det at hele lortet bliver cached pr. query, og deres ingen joins.
http://zkillboard.com
Stadig massere af ting der skal optimeres, f.eks. css, js og billeder.
Heldigvis så bliver databasen hurtigere af at flere bruger siden, i det at hele lortet bliver cached pr. query, og deres ingen joins.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund