09. august 2010 - 21:02Der er
10 kommentarer og 2 løsninger
cachin to be or not to be
Hej,
(Ved det er en kryptisk overskrift...)Forklaring:
Jeg bruger normalt UnoEuro som webhotel og er i gang med at lave et site, hvor jeg ved, der bliver omkring 1000 brugere på. Af samme årsag, vil jeg jo gerne optimerer sitet så meget som muligt. Så jeg gik ind på UnoEuro, for at se, hvad de forlanger af et site, for at de vil godkende den trafik 1000 brugere medfører....
Der kunne jeg så læse at de skrev at caching er en god ting: "Som kunde kan man gøre meget selv for at mindske belastningen. Installation af cache moduler i blog og CMS systemer er ofte kun et spørgsmål om et klik eller to, og kan nemt gøre forskellen på at håndtere 10 hits og dagen og overleve 10.000 hits pga. pludseligt populært indhold."
Jeg har derfor cached alt, jeg henter fra databasen. Så skrev jeg til UnoEuro, fordi jeg havde et par tillægs spørgsmål og der skrev de så til mig:
"Cache foregår normalt i statiske filer, og ikke i RAM, så derfor er cache altid en god ide og løser ofte performance problemer."
Nu er det jeg så er mega meget forvirret......
For hvad jeg har læst/lært om caching, så foregår det i rammen (også det der sker på mit site) - altså jeg henter en tabel med X antal rækker fra databasen - som jeg putter i cache. Næste gang den så skal bruges så istedet for at hente fra databasen så henter den fra cache (= rammen/hukommelsen).....
Hvad mener de med caching foregår i statiske filer? Er det normalt at cache til statiske filer? (hvis ja - hvor kan jeg læse noget om, hvordan og hvorledes)
En traditionel data cache er ganske rigtigt data som gemmes i memeory og derfor ikke hentes fra databasen hver gang.
I CMS sammenhaenge bruger man nogen gange det at i.s.f. at have et dynamisk script som henter indhold fra databasen, saa genererer man en statisk HTML udfra data og lade web serveren server den.
Formålet med caching er vel i bund og grund at du gemmer data i en form som er mindre resursekrævende at fremskaffe end hvis du ikke cachede dem. Om det så involverer RAM eller en fil er som sådan underordnet.
Hvis Uno Euro hoster mange sites på samme server, kan jeg sagtens forstå at de vil promovere filcaching over RAM-caching, da RAM er væsentlig dyrere pr. Mb end harddisk (og hvis alle sites indlæste deres databaser til RAM, så ville det nok hurtigt fylde en servers kapacitet op).
Hvis man betragter performance for statiske filer kontra dynamisk genererede filer, så er statiske filer med stor sandsynlighed hurtigere for serveren at fremskaffe, da det i bund og grund bare er et spørgsmål om at læse filen og sende den til browseren, hvorimod dynamisk genereret indhold jo skal igennem en form for fortolkning inden den kan sendes til browseren. Dette gælder også for compileret kode :-)
Caching til statiske filer er vist mest holdbart for sider som ikke ændrer sig voldsomt og hvor der ikke er så mange variationer er indholdet på siderne (altså hvor sidernes generering er styret af få eller ingen parametre). Hvordan det skal gøres i praksis afhænger meget af din løsning, men grundliggende drejer det sig om at generere en htm-side der så refereres til på dit site. Når de data som ligger til grund for siden så ændrer sig, genererer du en ny htm-fil (med samme navn), så indholdet følger datagrundlaget...
Både ja og nej. Statiske filer kan på en IIS også caches.
Du kan også lave cache i RAM'en som du har gjort lige nu, hvilket altid er det første jeg ville gøre.
Cache er statiske filer, mener de at skrive dem ned til disken som HTML filer ... og så læse den derfor. Kan også være du lave billeder med informationer ud fra en database, det er nok mere sådan noget som man bør skrive ned til filer.
Men 1000 brugere skal du nok definere lidt bedre ... er det 1000 samtidige brugere? 1000 brugere som kommer ind en gang i løbet af en dag ? Jeg ville ikke gøre noget specielt for at lave "pre mature optimization", sagt på en anden måde. Lad være med at optimere før det bliver et problem eller du er helt sikker på at noget er langsomt og vil sløve der servere meget ned. Kan være meget komplekse quries, som tager 1 sek. Dem ville jeg nok kigge på i første omgang. Tager de 10-20 ms sek, så ville jeg ikke gøre noget.
Men ... først, beskriv mere forklarende hvordan din beslatning af brugere er udover et døgn.
1000 brugere om dagen alle laver 50 request.
50000 request på en dag fordelt udover 86400 sekunder. Det er under et hit per sekund over et døgn, og det er ikke specielt meget.
Jeg kan høre, jeg skulle have spurgt herinde inden jeg overhovedet gik igang *suk*
Først til spørgsmålet omkring brugere - det er ikke 1000 samtidige brugere - men brugere i alt. Der vil være omkring 50-70 samtidige brugere og det døgnet rundt. Men det skal så tilføjes, det er så meget aktive brugere, som uploader billeder, skriver blogs - gæstebøger - debatterer osv (altså dermed har I nok gættet det er et community jeg er igang med at lave).... Jeg aner slet og ret ikke hvor mange requests de laver.
Som skrevet har jeg lavet det sådan, at det cacher alt, hvad jeg henter fra databasen. Når der så sker ændringer i databasen sletter jeg selvfølgelig den pågældende cache entry....
Hvad er bedst - at lade den cache (som nu) - eller fjerne caching af det jeg henter fra databasen? Og jeg tænker performance mæssigt...
Så en anden ting - som jeg ikke har fundet en løsning på - jeg har to forskellige ting, jeg gør med billeder - jeg har en UserControl - hvor jeg henter informationer om billeder den enkelte bruger har uploadet og viser de forskellige billeder fra filsystemet. Den UserControl bruger jeg jo for hver enkelt bruger der er i systemet. Den anden måde er at jeg har en UserControl = webside, hvor jeg viser samtlige billeder alle brugere har uploadet - inddelt i kategorier....
Når siden engang kommer op at køre, kan der blive tale om 1000vis af billeder, så siden hvor jeg loader alle billederne kan jo gå hen og blive langsom - så vil den være smart at cache - og hvordan gør jeg det (altså link til et eller andet jeg kan læse mig til)?
Mht. billedesiderne, så bør du nok benytte paginering, så der ikke vises mere end et begrænset antal ad gangen. Billederne bliver indlæst som separate dokumener fra webserveren, så jo flere du smider på en side desto længere tid vil siden tage om at blive færdig med at indlæse.
Husk at sæt expire date i fremtiden hvis billeder ikke ændre sig, på den måde kan du også gøre brug af browserens cache, så de ikke skal hentes hver gang, og den ikke skal ramme serveren for at finde ud af at billedet faktisk ikke har ændret sig.
Det kan altid betale sig at cache hvis du har RAM nok, problemet at at holde styre på hvad der i cachen skal invalideres, fordi en bruger har lavet nogen opdateringer.
Cache FTW, leger selv meget med det lige nu. 300 single request fra databasen tager 1 sek, samme fra cache tager: 0.00005 sek. Så ... du kan se der er noget at spare, men om det kan betale sig ... tjaaaa, det er meget svært at sige. Fra 200 ms til måske 100 ms ... for at lave en side betyder ikke så meget hvis brugeren i den anden ende alligevel tager 2 sekunder om at hente og vise siden, så er det på client siden jeg ville starte med at lave optimeringer.
Der er MEGA mange ting man kan gøre ... :-)
Jeg ville ikke bekymre mig så meget om du måske skulle bruge for mange resources, så skal de nok advare sig, og så ville jeg nok gøre noget ved det ...
bare husk, lad være med at gøre noget til et problem, før det reelt set er det ...
softspot Jeg spørger sikkert dumt - men mener du med paginering paging? Hvis det er tilfældet - så benytter jeg mig af det - Jeg har dog valgt at lade brugeren selv bestemme om han vil se 10-500 billeder af gangen.
buzzz Mht. at billederne er alt for store.... så gør jeg allerede det nu, at jeg laver thumbnails af alle billeder og de der vises på de to sider, jeg har skrevet om - jeg har så også et link til en UserControl, hvor billedet i original størrelse vises.
Jeg kan se at webimageresizer er en online en af slagsen, så den kan jeg ikke bruge (pga. den måde, jeg viser billederne på)
Minify af css/js filer har jeg faktisk aldrig hørt om før nu...Så det vil jeg google noget på de næste dage og se, hvordan og hvorledes....For der er måske noget at hente - jeg har flere af slagsen og de er temmelig "store".
Jeg har ram nok - men jeg aner ikke hvad UnoEuro har *griner* Men lige nu er jeg så forvirret, at jeg ikke aner om jeg skal bibeholde caching eller ej..... Men jeg tror nu nok jeg ender op med at cache - jeg kan på et par af de tunge sider (hvor der bliver kaldt til databasen MANGE gange), mærke når den henter fra cached og den dermed ikke trækker fra databasen.
Min bekymring er alene, at jeg ved, der findes et tilsvarende portal, som har flyttet webhotel et par gange.....fordi de har for meget run på deres side.....Den situation vil jeg ikke ende op i - så derfor mine bekymringer om performance.....
buzzz og softspot Jeg skal have ting ind med skeer - så spørger lige igen.... Mht. de billeder - skal jeg cache den usercontrol hvor jeg viser billederne (altså thumbnails af billederne) eller bare lade den være, som den er nu, hvor den ikke gør noget?
Og er der forskel på om jeg cacher en side med 10 billeder og en side/UserControl med 100 billeder i rammen?
Og så må du softspot godt lægge et svar også - du og buzzz får lov til at deles
Og tak for hjælpen - nu har jeg masser af nyt, jeg skal google mig til :-)
Mht. caching af usercontrol, så er det jo kun selve markup der bliver cached når du gør det, så de billeder der vises på siden vil stadig skulle caches på anden vis.
Jeg er overordnet enig med buzzz i, at man skal gøre tingene når det er nødvendigt (måske lidt før ;-)). Mht. hvad der skal caches, så vil jeg foreslå at du cacher de sider og data, som hentes ofte eller er langsomme uden cache og lader de øvrige ligge uden cache. Implementering af caching har en tendens til at gøre tingene mere komplicerede...
Scripts og stylesheets skal nok, som udgangspunkt "komprimeres", da der ellers er tale om ren spild (hd, ram, båndbredde) selvom disse, ligesom med billeder, vel af de fleste browsere, vil blive cached indtil browsercachen bliver slettet.
Lige en kommentar mere til det med antallet af billeder på en side og at lade brugeren bestemme hvor mange resurse du skal bruge på din server... jeg mener princippielt ikke brugeren skal have så stor frihed til at sluge resurser fra din server, som han kan komme til hvis der skal downloades 500 thumbnails.
Desuden er det efter min bedste overbevisning de færreste, der har brug for, endsige lyst til at kigge 500 små billeder igennem. Jeg ville overveje en mulighed for at søge i disse tilfælde. Det er naturligvis helt uden at vide hvad kravene til dit system er, men sådan en generel betragtning... :-)
Tak for jeres svar - jeg er glad for, jeg har fået noget til at grave videre i emnet :-)
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
