Kirjoittaja Aihe: Sivustojen cache-asetukset  (Luettu 8784 kertaa)

Sami Lehtinen

  • Käyttäjä
  • Viestejä: 726
  • Techie
    • Profiili
    • Sami Lehtinen
Sivustojen cache-asetukset
« : 08.04.12 - klo:09.53 »
Firefoxin välimuisti (cache) aiheuttaa kiusoja tarjotessaan "vanhasta muistista" sivun tai ladattavan tiedoston.  

Koodia: [Valitse]
Cache-Control: private
Expires: Sat, 26 Jul 1997 05:00:00 GMT

Hmm, mielestäni tuossa yhteydessä voisi tai pitäisi ilmoittaa myös no-cache, no-store toisaalta siellä on kyllä expires tagi joka on historiassa. must-revalidate voisi olla ihan asiaa.

Mielestäni cachen kääntäminen pois päältä on täysin väärä toimenpide. Välimuistin tehokkuuteen kannattaa nimenomaisesti panostaa. Olen tästä aiheesta useammankin kerran kirjoitellut ja joka kerta sanoman on aivan sama.

Mielestäni olisi myös erittäin järkevää käyttää etagia tuossa lisänä, jolloin tietoa ei tarvitsisi siirtää uudelleen turhaan, mikäli sisältö ei ole muuttunut. En juuri nyt muista aivan eksaktisti miten nuo RFC:n mukaan menee, mutta kyllä noilla eväillä pitäisi pärjätä ilman ongelmia 100% varmasti, kunhan homman tekee oikein.

No joo, ihan normi settiä. Huonosti tehdyt saitit kun on enemmän sääntö, kuin poikkeus.

Ajattelinkin muuten kirjoitella tässä blogiin juuri artikkelin siitä, kuinka tietokonemaailmasta tuttuja garbage collect ja cache algoritmejä voidaan hyödyntää kotona tavaramäärän hallintaan.

Lainaus
     2. If the response includes the "must-revalidate" cache-control
         directive, the cache MAY use that response in replying to a
         subsequent request. But if the response is stale, all caches
         MUST first revalidate it with the origin server, using the
         request-headers from the new request to allow the origin server
         to authenticate the new request.

Ja sitten...

Lainaus
private
    Indicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache. This allows an origin server to state that the specified parts of the
    response are intended for only one user and are not a valid response for requests by other users. A private (non-shared) cache MAY cache the response.

    Note: This usage of the word private only controls where the response may be cached, and cannot ensure the privacy of the message content.

no-cache
    If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests.
    If the no-cache directive does specify one or more field-names, then a cache MAY use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, the specified field-name(s) MUST NOT be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response.

    Note: Most HTTP/1.0 caches will not recognize or obey this directive.

IMHO, forumin headerit eivät välttämättä ole oikein.

Tuossa kevyt kertaus muillekkin nörteille asiasta: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Valitettavan monet sivustot eivät osaa hyödyntää välimuisteja oikeaoppisesti.
« Viimeksi muokattu: 08.04.12 - klo:09.55 kirjoittanut Sami Lehtinen »

ajaaskel

  • Palvelimen ylläpitäjä
  • Käyttäjä
  • Viestejä: 3384
    • Profiili
Sivustojen cache-asetukset
« Vastaus #1 : 08.04.12 - klo:12.55 »
Lainaus
Mielestäni cachen kääntäminen pois päältä on täysin väärä toimenpide.

Kokonaisuuden kannalta teknisesti näin voidaan sanoa ja hyvin toimiva cache on kaunis tavoite.  Kuitenkin käytännössä et pysty vaikuttamaan siihen miten ne websaitit ovat toteutettu (kuten mainitsitkin)  joita käytät, ne ovat siellä jo valmiina sellaisena kuin ovat.  Sen sijaan voit vain itse varautua että kaikki ei toimi niin kuin odottaisit ja tuohon tarkoitukseen cachen pimentäminen selaimessa auttaa.

Vaakakupissa ovat:
  • Hyöty:  Saat alkuperäisen datan suoraan webbipalvelimelta, myös latauksissa (download)
  • Haitta:   Datan tulo viipyy hitusen pidempään (yhteysnopeutesi mukaisesti)

  
Kokemusperäinen havainto lisäksi (en puhu nyt tästä Ubuntun foorumista vaan teknisestä ideasta kaikenkaikkiaan):  Websaitin pitäjä voi olla jo tehnyt yrityksen webbisivun direktiiveillä varmistaa että vanhoja sivuja ei voi vetää webbiselaimen muistista.  Muuten hyvä mutta ei toimikaan download-tilanteessa, webbiselain näyttää tuoreita html-sivuja mutta "tiputtaaakin" ladattavan tiedoston cache:sta tai siis oikeastaan valetiputtaa.  Webbiselain ei varmaankaan tulkitse mitään jos tiedostolinkkiin käydään suoraan kiinni, eihän siellä edes ole välissä mitään html-sivua jonka direktiivejä tulkattaisiin.  

Ideani oli siis vain keksiä tapa jolla käyttäjä itse voi välttää tietyjä hankaluuksia.
« Viimeksi muokattu: 08.04.12 - klo:13.03 kirjoittanut ajaaskel »
Autamme ilolla ja ilmaiseksi omalla ajallamme.  Ethän vaadi, uhoa tai isottele näin saamasi palvelun johdosta.

Sami Lehtinen

  • Käyttäjä
  • Viestejä: 726
  • Techie
    • Profiili
    • Sami Lehtinen
Sivustojen cache-asetukset
« Vastaus #2 : 08.04.12 - klo:13.51 »
Muuten hyvä mutta ei toimikaan download-tilanteessa, webbiselain näyttää tuoreita html-sivuja mutta "tiputtaaakin" ladattavan tiedoston cache:sta tai siis oikeastaan valetiputtaa.  Webbiselain ei varmaankaan tulkitse mitään jos tiedostolinkkiin käydään suoraan kiinni, eihän siellä edes ole välissä mitään html-sivua jonka direktiivejä tulkattaisiin.  

Sillä onko kyseessä binääri data, html sivu, teksti tai mikä tahansa muu mime-tyyppi ei ole mitään tekemistä cachen toimimisen tai toimimattomuuden kanssa. Nyt se RFC kertaukseen. ;) Kyse on HTTP protokollan ominaisuudesta.

Henkilökohtaisesti suosin kohtuullisia expire timejä ja etagien käyttöä. Silloin sivut saadaan toimimaan nopeasti, eikä samaa dataa tarvitse siirtää moneen kertaan, eikä vanhaa dataa tule vahingossa. Joissain tapauksissa suosin myös erittäin pitkiä cache-aikoja, jotta tietoa ei tarvitsisi ladata turhaan uudelleen. Silloin kannataa lähteä siitä liikenteeseen, että urlia muutetaan joka kerta kun sisältö päivittyy. mm. Web-siten grafiikoissa tuo on oiva tapa, tietysti etagien lisäksi. Esimerkkiä voit estiä mm. tämän http objektin headereista: http://www.9ox.net/img/9ox.net-logo.png

Koodia: [Valitse]
Status: HTTP/1.1 200 OK
ETag: "8yBgOw"
Date: Sun, 08 Apr 2012 10:49:41 GMT
Expires: Mon, 08 Apr 2013 10:49:41 GMT
Cache-Control: public, max-age=31536000
Content-Type: image/png
Server: Google Frontend
Content-Length: 16060
Connection: close

Kuten huomaat, kuva on vuoden voimassa. Sen jälkeen tarkistetaan käyttäen etagia onko kuva muuttunut. Jos etagi täsmää, ei kuvaa siitäkään huolimatta siirretä uudelleen. Kuten tyypistä näky, kyseessä on PNG kuva, eikä HTML dokumentti. Jos jostain syystä tekisin logoon niin olennaisia muutoksia, että haluaisin sen näkyvän käyttäjille, muuttaisin kuvan urlia, niin että se ladataan uudelleen palvelimelta ja expiroituu selainten cacheista normaalin cache evictionin myötä.

Jos pyydän samaa objektia etagin kanssa, kuten silloin tehdään kun tiedot ovat välimuistissa ajantasalla, käy näin.

Koodia: [Valitse]
Status: HTTP/1.1 304 Not Modified
ETag: "8yBgOw"
Date: Sun, 08 Apr 2012 11:05:21 GMT
Server: Google Frontend
Connection: close

Eli mitään turhaa dataa ei tuon lisäksi siirretty. Mitä isompia tiedostoja, sitä valtavampi säästö.

Tästä aiheesta on lukemattomia artikkeleita olemassa, kvg. Välimuistien käyttö on myös aina suositeltavaa ja myös järjevää. -> Nopeammat palvelut, vähemmän turhaa liikennettä.

Jos jostain tulee "vanhaa dataa", on sen web-saitin ylläpitäjän tunaroineet jotain.
« Viimeksi muokattu: 08.04.12 - klo:14.07 kirjoittanut Sami Lehtinen »

ajaaskel

  • Palvelimen ylläpitäjä
  • Käyttäjä
  • Viestejä: 3384
    • Profiili
Sivustojen cache-asetukset
« Vastaus #3 : 08.04.12 - klo:17.58 »
Et käsittänyt mitä sanoin tai et halunnut kommentoida mitä sanoin.  Ei siinä ole mitään uutta että cache vähentää liikennettä kun tavaraa ei oikeasti haeta sieltä palvelimelta asti.  
Et myöskään kiistänyt mitä sanoin paitsi että esitit että jos webbiselaimella käydään url: iin kiinni minkä takana on suoraan tiedosto (eikä mitään html-sivua) niin jostain ( mistä ?)   tulkitaan direktiivejä (jorka ovat sivulla johon ei lainkaan koskettu).    
Kerropa lyhyesti tarkemmin:
  • Miten sellaisen webbisivun jolla ei käydä lainkaan otsikkokentän cache-direktiivi vaikuttaa webbiselaimen toimintaan (kuten esität).
      
    Oma havaintoni on vastakkainen mutta olen toki utelias.
« Viimeksi muokattu: 08.04.12 - klo:18.00 kirjoittanut ajaaskel »
Autamme ilolla ja ilmaiseksi omalla ajallamme.  Ethän vaadi, uhoa tai isottele näin saamasi palvelun johdosta.

Sami Lehtinen

  • Käyttäjä
  • Viestejä: 726
  • Techie
    • Profiili
    • Sami Lehtinen
Sivustojen cache-asetukset
« Vastaus #4 : 08.04.12 - klo:18.59 »
Et käsittänyt mitä sanoin tai et halunnut kommentoida mitä sanoin.  Ei siinä ole mitään uutta että cache vähentää liikennettä kun tavaraa ei oikeasti haeta sieltä palvelimelta asti.  

Kommunikaatikatko tuntuu olevan vähintään molemminpuolinen. ;)

Lainaus
Et myöskään kiistänyt mitä sanoin paitsi että esitit että jos webbiselaimella käydään url: iin kiinni minkä takana on suoraan tiedosto (eikä mitään html-sivua) niin jostain ( mistä ?)   tulkitaan direktiivejä (jorka ovat sivulla johon ei lainkaan koskettu).    

Direktiiveillä ei ole mitään tekemistä "sivun/html:n" kanssa. Vaan HTTP requestin ja sen headereiden kanssa.

Lainaus
Kerropa lyhyesti tarkemmin:
  • Miten sellaisen webbisivun jolla ei käydä lainkaan otsikkokentän cache-direktiivi vaikuttaa webbiselaimen toimintaan (kuten esität).
    Oma havaintoni on vastakkainen mutta olen toki utelias.
Määrittele vielä tarkemmin mitä tarkoitat kun sanot, että ei käydä lainkaan? Lataat siis tiedoston paikallisesti? Tai FTP:llä? Jos käytössä on HTTP protokolla, on aivan pakko "käydä sivulla", jotta sen sisältö saadaan, ellei se tule cachesta ja jotta tieto voisi olla cachessa, on sivulla pakko käydä aikaisemmin.

Cachessa ei ole mitään ihmeellistä, eikä mitään ongelmaa jos sitä käytetään oikein. Kieltämättä aina joskus ajaa miinaan liian pitkien cache-aikojen kanssa (ttl), jos ei ajattele riittävästi ennakkoon ja sitten tekee jotain olennaisia muutoksia. Mutta tämä on täysin geneerinen asia, eikä tällä ole mitään tekemistä nettisivujen kanssa sinänsä.

Tässä esimerkki tiedostosta joka on aina tarkistettava (etagilla) tai muuten, jos selain tarvitsee sitä:
http://www.sami-lehtinen.net/Sami_Lehtinen_photo.png
Jotta kuva näkyy, sinun on pakko käydä "sivulla" jonka osoitetta juuri klikkasit.

Nyt se RFC käteen ja lukemaan, kannattaa muuten samalla tutustua SPDY:n ja HTTP SM:n featureihin. SPDY:n tekniikka kuten SDCH tuo paljon uutta hanskattavaa selaimelle.

Tuossa vielä olennaiset osta tuosta mun kuvasta, joka varmistaa sen että tietoa _saa_ käyttää cachesta, jos kuva ei ole vaihtunut uuteen. Mutta jos se on vaihtunut, on pakko ladata uusi.

Koodia: [Valitse]
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT

Mutta jees, eiköhän tää ole selvää, palataan alkuperäiseen aiheeseen ja sillä selvä.

Todennäköisesti jos sulla on ongelmia sen kanssa että saat jostain "vanhaa dataa", niin joku tunari on konffannut systeemit toisessa päässä väärin. Se ei ole tavatonta, asia ratkeaa ojentamalla epäpätevää ylläpitoa. ;)

ajaaskel

  • Palvelimen ylläpitäjä
  • Käyttäjä
  • Viestejä: 3384
    • Profiili
Sivustojen cache-asetukset
« Vastaus #5 : 09.04.12 - klo:01.08 »
Lainaus
Määrittele vielä tarkemmin mitä tarkoitat kun sanot, että ei käydä lainkaan? Lataat siis tiedoston paikallisesti? Tai FTP:llä? Jos käytössä on HTTP protokolla, on aivan pakko "käydä sivulla", jotta sen sisältö saadaan, ellei se tule cachesta ja jotta tieto voisi olla cachessa, on sivulla pakko käydä aikaisemmin.
1) Vika ei ole nyt RFC-dokumenteissa, ei niiden lukemisessa eikä lukematta jättämisessä.  Niitäkin olen lukenut jossain määrin --- silloin kun koen olevan oikeaa tarvetta.  Ei tuossa ole mitään ihmeellistä eikä uutta mihin tarvittaisiin RFC-dokumentteja. Toki asioita voi tehdä niinkin eli aina pienemmästäkin syystä lukien RFC: tä mutta kuluu tämä elämän aika muutenkin.  En ymmärrä miksi ajattelet niin monimutkaisesti.
2) Tarkoitan sitä aivan pilkulleen mitä sanon.  Kun tiedosto ladataan linkistä jota ei ole upotettu mihinkään html- tai muuhunkaan webbisivuun niin siellä ei ole matkalla mitään "no cache" tai "uudistusaika=0" -määritystä.   Oma esimerkkisi ei ollut sellainen mistä oli puhe, kuvasi on upotettu html-koodiin.  
3) Ei tiedostoa tarvitse ladata paikallisesti eikä ftp: llä että tuon tilanteen saa aikaan.  
Tuota voit testata erittäin helposti, ei tarvita muuta kuin että laitat jonkun hakemiston jossa on mitä hyvänsä tiedostoja jakoon sellaisenaan webbipalvelimella. Vaikka Apachella omalla koneellasi.  Ilman mitään html-koodia.   Mikä ohjaa webbiselaimen cache-toimintaa ?    Ymmärtänet nyt varmaan mitä tarkoitan (?).

Lähestymistapamme ongelmaan ovat aivan eri planeetalta:  Sinä teloituttaisit webbipalvelimen pitäjän välittömästi (luettuasi ensin RFC-dokumentit ja ainakin jos asuisimme sellaisessa valtiossa missä kuolemanrangaistus on sallittu), minä taas pyrin yksinkertaisesti väistämään ongelman omalla toimellani jonka pystyn heti itse tekemään.    :)



 
« Viimeksi muokattu: 09.04.12 - klo:01.11 kirjoittanut ajaaskel »
Autamme ilolla ja ilmaiseksi omalla ajallamme.  Ethän vaadi, uhoa tai isottele näin saamasi palvelun johdosta.

mrl586

  • Käyttäjä
  • Viestejä: 4507
    • Profiili
Sivustojen cache-asetukset
« Vastaus #6 : 10.04.12 - klo:02.30 »
Sillä onko kyseessä binääri data, html sivu, teksti tai mikä tahansa muu mime-tyyppi ei ole mitään tekemistä cachen toimimisen tai toimimattomuuden kanssa.
Väitän päinvastaista, sillä www-palvelimen ylläpitäjä voi määritellä, miten palvelimen cachettaa erilaiset tiedostotyypit. Kaikkea ei välttämättä laiteta välimuistiin.

Sami Lehtinen

  • Käyttäjä
  • Viestejä: 726
  • Techie
    • Profiili
    • Sami Lehtinen
Sivustojen cache-asetukset
« Vastaus #7 : 13.04.12 - klo:19.26 »
Väitän päinvastaista, sillä www-palvelimen ylläpitäjä voi määritellä, miten palvelimen cachettaa erilaiset tiedostotyypit. Kaikkea ei välttämättä laiteta välimuistiin.

Totta kai serverillä voi jokaiselle objektille määritellä dynaamisesti expire ajankohdat tai maxage:t ihan miten ylläpito ikinä haluaa. Se millä kriteereillä nuo asiat tehdään, on http-protokollan ulkopuolella, ja säännöstö voi olla käytännössä rajaton. Kuten jo aikaisemmin laitoinkin muutaman esimerkin. Jos tiedän, että tämä objekti päivitetään joka päivä kello 8:32:22 niin voin laittaa sen expiroitumaan 8:32:23. Jos Etag täsmää edelleen, ei objektia tarvitse ladata uudelleen vaikka sen tuoreus tarkistettiin.

HTTP-protokollan kannalta siis Mime-type on yksi teksti muiden joukossa, eikä se sinänsä vaikuta cachen toimintaan. Se millaista serveri softaa ja konfiguraatiota käytät, ei vaikuta HTTP-protokollan ja selain välimuistien toimintaan.

Jos jaksaisin tehdä regexp samplen, niin voisin pasteta tähän configin, joka määrittelee cachen expiroitumisen tiedoston nimen toisen kirjaimen mukaan. Mutta ei just nyt jaksa millään.

mm. Apachen configissa näitä voi viljellä aikalailla vapaasti.

Esimerkki 1, mun Apache2 serveriltä:
Koodia: [Valitse]
 ExpiresDefault "access plus 1 day"
  ExpiresActive on

Esimerkki 2, mun Nginx serveriltä:
Koodia: [Valitse]
 expires 1d;

Esimerkkinä: Apache2 / mod_expires.  joka on vain yksi serverei muiden joukossa.  Apachen tapauksessa myös käyttäjät voivat tunkata noita itse .htaccess:ia käyttämällä.

Helppoa, yksinkertaista, perussettiä, perussettiä, sano.

P.S. Nyt on myös muuten uudet testiserverit Helsingissä ja Lontoossa, uudella pilvipalvelun tarjoajalla. Pitäs vielä niitä ehtiä vähän tunkkaamaan.

Edit, otetaan vielä yksi esimerkki.

9ox.net päivittää omaan tietokantaan last access time stampin 24 tunnin välein. Jotta saan tuon last access timestampin täsmälleen oikeaksi, annan dynaamisesti jokaisessa redirect vastauksessa seuraavan urlin päivitys ajan expires kentässä.

Näin ollen jos avaat sivun vaikka kerran tunnissa, saat ensimmäisellä pyynnöllä 24 tuntia aikaa. Mutta jos joku toinen käyttäjä avaa sivun sun jälkeen esim 4 tunnin kuluttua, saa hänen selain vain 20 tuntia aikaa. Eli jokaiselle pyynnölle määritellään dynaamisesti expires ajankohta. Tämä siksi että kun tuo 24 tuntia tulee täyteen, niin se voi olla myös käyttäjä X joka triggaa 24 tunnin välein tehtävän tarkistusprosessin urlille.

Tällä varmistan että minkään selaimen välimuistissa ei ole vanhentunutta tietoa, koska periaatteessa tarkistus ajankohdan jälkeen urlin forwardi voi osoittaa jonnekkin muualle. Ei ole todennäköistä, mutta kun teen jotain, pyrin tekemään sen oikein. Enkä vain vähän jotain sinne päin. Varsinkin silloin kun opiskelen asioita.

Tietysti jos hittejä tulisi ihan tolkuttomasti, niin sitten voisi lisätä ihan muutaman sekunnin randomin tuohon expireen jokaiselle clientille, ettei ne kaikki ala refreshaamaan samaan aikaan. Lisäksi muutama sekunti tai ehkäpä jopa pari minuuttia yliaikaa olisi hyvä lisätä clock skewin takia.

Sitä ei tule helposti ajatelleeksi kun käyttää koneita joissa on NTP käytössä. Mutta kaikilla ei ole koneiden kellot millisekunnin tarkkuudella oikeassa ajassa. Tällöin voi käydä niin että jos selaimen kello on edellä se hakee objektin liian aikaisin. Juuri tässä tilanteessa auttaa se että on määritelty absoluuttinen expires ajankohta, eikä expires aika. Ai miksi? No koska silloin tuo uudelleen haettu objekti on myös vanhentunut ja tarkistuksia jatketaan kunnes serverille tulee myös uusi objekti ja sitä myöten tulevaisuuteen osoittava expires headeri.

Oliko muita kysymyksiä tämän asian suhteen?

Tässä vielä cachetuksen estäminen oikea-oppisesti palvelimen päässä, esimerkki mun SMTP Status checker Python 3 scriptin header ostiosta:
Koodia: [Valitse]
CacheControlHeader='Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0'
Mime typellä ei ole mitään tekemistä tämän kanssa.

Mikäli objekti halutaan päivittää usein vieraillulla sivulla kätevästi, ilman että käyttäjä edes oikeastaan huomaa päivitystä voidan käyttää tuota post-check parametria. Sen avulla selain päivittää objektin omaan välimuistiinsa, mutta vasta sivun näyttämisen jälkeen. Tämä on ihan loistava juttu jos päivitetään vaikka jotain pieniä graafisia komponentteja sivustolle, joiden tarkistaminen joka sivunlatauksen yhteydessä ei todellakaan ole välttämätöntä.

Eli kun avaat sivun, se tulee heti näkyviin, kun tulet sivulle uudestaan logo tms juttu on päivittynyt. Sen päivittäminen ei vain ollut prioriteetti heti ennen sivun näyttämistä.

Cachejen käyttöä ei sitten tule unohtaa "vain" selain tasolle, vaan ne pitää muistaa myös koko palvelin systeemien suunnitelussa ja toteutuksessa. Tässä esimerkki 9ox.net ja App Engine ratkaisusta joita käytän.

Todella surkeat websivustot huomaa siitä, että cachetus ei ole hallussa. -> Hitaat sivut, vaatii paljon kaistaa, vaatii paljon cpu tehoa, vaatii paljon levy i/o:ta. Näitä esimerkkejä on valitettavasti maailma ihan pullollaan, jos cachetusta ei ole ajateltu yhtään kun järjestelmää on rakennettu.

mm. Poliisin sivujen kaatuminen salasana uutisten levitessä viittasi vahvasti siihen, että niiden sivut on todella amatöörien toteuttamia. Katsomalla niiden sivujen headereita ja järjestelmän suorituskykyä, kuten miten nopeasti http requestin lähettämisen jälkeen vastaus tulee, käy selväksi että tehokasta välimuistitusta ei näköjään ole käytössä. Taustalla on näköjään käytössä pommi eli Lotus-Domino.

Erilaisia optimointiartikkeleita luettuani tulin siihen tulokseen, että helposti tekemällä järjestelmä vähän fiksummin, voidaan palvella jopa 1000 kertainen määrä kävijöitä aivan samalla palvelin kapasiteetilla. Kaikki data tulee suoraan muistista ja iso osa suoraan selaimen muistista, eikä kaikkea tarvitse aina hakea esimerkiksi palvelimen SQL kannasta tai levyltä.

Huonosti toteutetut sivut johtavat myös siihen, että niiden kaataminen mm. DDoS hyökkäyksillä on helppoa, koska järjestelmän suorituskyky on surkea. Pahimmillaan palvelut kaatuvat Poliisin esimerkin mukaisesti jo hieman normaalista poikkeavan käyttäjäkuormituksen alla. Puhumattakaan sitten massiivisesta DDoS hyökkäyksestä tai Slashdot / Hacker News-efektistä.

Tuossa on mulla testikäytössä palvelin jossa on 2x6 coresta Xeonia, jotka yhteensä siis ajavat 24 threadia. Olisi kiva kokeilla millä vauhdilla tuo mylly pyörii jos käännän kaikki prosessorin ja emolevyn cachet pois päältä. Onnistuukohan tuo edes enää nykyaikana? Joskus 486 aikaan sai vielä cachet päälle tai pois. Olisi kiva nähdä miten hommat etenee jos cachetus poistetaan käytöstä ja kaikki prosessorin datan lataukset jouduttaisiin tekemään suoraan keskusmuistista. Voisi olla aika hilpeää. Arvauksia paljonko benchmark arvot laskisivat? Tämä siis tietenkin ihan vain leikki mielessä, mutta esimerkkinä siitä miten paljon merkitystä järkevällä välimuistituksella on järjestelmän suorituskyvyn kannalta.
« Viimeksi muokattu: 14.04.12 - klo:11.34 kirjoittanut Sami Lehtinen »

ajaaskel

  • Palvelimen ylläpitäjä
  • Käyttäjä
  • Viestejä: 3384
    • Profiili
Sivustojen cache-asetukset
« Vastaus #8 : 15.04.12 - klo:09.51 »
Sami, viestisi on mielestäni ylipitkä, en pysty varaamaan aikaa sen käsittelyyn ja kommentointiin enkä halua myöskään käyttää palstatilaa siihen.  
Autamme ilolla ja ilmaiseksi omalla ajallamme.  Ethän vaadi, uhoa tai isottele näin saamasi palvelun johdosta.

Sami Lehtinen

  • Käyttäjä
  • Viestejä: 726
  • Techie
    • Profiili
    • Sami Lehtinen
Sivustojen cache-asetukset
« Vastaus #9 : 15.04.12 - klo:09.58 »
Sami, viestisi on mielestäni ylipitkä, en pysty varaamaan aikaa sen käsittelyyn ja kommentointiin enkä halua myöskään käyttää palstatilaa siihen.  

Jostain aiheista on pakko kirjoittaa vähän pidemmästi. Miksi? Siksi, että muuten syyllistyy helposti aivan liialliseen yleistämiseen ja sitä kautta virheelliseen informaatioon. Kuten alan lehdet syyllistyvät jatkuvasti. Joko asiaa on käsiteltävä todella suppeasti tai sitten materiaalin määrän pitää kasvaa huimasti tai sitten yleistetään ja monta monta asiaa jää huomioimatta.

Tässä vielä kevyttä lisätietoa välimuistituksen merkityksestä: http://www.stevesouders.com/blog/2012/03/22/cache-them-if-you-can/

Lisää cache-horinaa, joskin ihan yleisessä tietotekniikka mielessä:
http://forum.ubuntu-fi.org/index.php?topic=42389.msg326789#msg326789
Tämä lähti liikenteeseen hybridi kiintolevyistä.

« Viimeksi muokattu: 29.04.12 - klo:16.12 kirjoittanut Sami Lehtinen »

Sami Lehtinen

  • Käyttäjä
  • Viestejä: 726
  • Techie
    • Profiili
    • Sami Lehtinen
Vs: Sivustojen cache-asetukset
« Vastaus #10 : 21.05.12 - klo:18.54 »
Tässä vielä hyvä kompakti perusteisiin paneutuva artikkeli:

http://www.mnot.net/cache_docs/

Siinäpä kevyttä iltalukemista uteliaille.


Sami Lehtinen

  • Käyttäjä
  • Viestejä: 726
  • Techie
    • Profiili
    • Sami Lehtinen
Vs: Sivustojen cache-asetukset
« Vastaus #11 : 30.01.13 - klo:17.30 »
Vielä ihan lyhyt bump tähän asiaan, otin cache tilastot kuukauden ajalta. Perus Firefoxin cache säästi verkkokaistaa kuukauden aikana: 1008764296 tavua, eli karkeasti yhden gigatavun verran. Mielestäni ei ole siis lainkaan hyvä idea kytkeä mm. cachea pois päältä selaimessa. Tähän tulokseen päästiin noin kuukauden aikana kerrytetyllä cachen käyttöhistorialla ja 250 megatavun cachella ja päivittäisellä normi surffauksella (hitaalla yhteydellä). Joten nopealla yhteydellä voisin säästöjen kuvitella olevan helposti jopa nelinkertaiset.

Vähän pidempää stooria tulee varmaan sunnuntaina blogiin tästä aiheesta.