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ä:
ExpiresDefault "access plus 1 day"
ExpiresActive on
Esimerkki 2, mun Nginx serveriltä:
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:
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.
Aihe: Sivustojen cache-asetukset (Luettu 15978 kertaa)
