Glitre

19.08.2010

Visualisering av mellomlagringsstrategi

Filed under: Logging,Mellomlagring,Sortering — magnusenger @ 11:34

For å kartlegge suksessen til mellomlagringen av Z39.50/SRU søk er det innført et enkelt logg-system, som skriver følgende informasjon til en ren tekst-fil:

  • Dato og tid for forespørselen
  • Hvilken side i trefflisten som be etterspurt
  • Hvilket bibliotek det ble søkt mot
  • Hva det ble søkt etter
  • Og ikke minst hvordan mellomlageret fungerte. Her brukes følgende «koder» :
    • nocache = søket ble ikke funnet i mellomlageret og et nytt søk ble utført mot den valgte Z39.50/SRU tjeneren
    • raw = søket ble funnet i mellomlageret, men ikke sortert på den måten som ble etterspurt, den opprinnelige trefflista (i MARCXML-format) ble hentet fra mellomlageret og sortert på ønsket måte
    • sorted = søket ble funnet i mellomlageret, ferdig sortert

For å gjøre det enklere å følge med på hvordan mellomlagringen fungerer er det laget en liten visualisering (kildekode) som viser innholdet i loggen og en grafisk fremstilling av forholdet mellom de tre mulige utfallene som er skissert ovenfor. Dataene oppdateres hvert 10. sekund, slik at man kan følge utviklingen i tilnærmet sanntid. (NB! Loggen vil bli tømt med ujevne mellomrom.)

Tanken er at denne loggingen og visualiseringen bare er starten på et system som skal gjøre det enkelt å overvåke bruken av en Glitre-installasjon.

Advertisements

12.08.2010

Mellomlagring

Filed under: Mellomlagring,Sortering — magnusenger @ 11:10

Det tar tid å hente poster fra Z39.50- og SRU-tjenere. Hvis det samme søket skal utføres to eller flere ganger med rimelig kort mellomrom er det liten vits i å hente trefflista fra tjeneren på nytt den andre (og tredje osv) gangen. Derfor har Glitre nå implementert mellomlagring (caching) av søkeresultater. Dette gjøres i to nivåer:

  1. De «rå» søkeresultatene lagres
  2. Søkeresultatene lagres etter at de har blitt sortert

Fordelen med dette er som følger: La oss si at to brukere utfører akkurat det samme søket med kort tids mellomrom, la oss kalle det Søk1 og Søk2. Søk1 medfører at postene hentes fra tjeneren og mellomlagres. Så sorteres de i tråd med brukerens ønske (eller standard sortering), og resultatet av dette mellomlagres. Når så Søk2 kommer, og ber om å få postene i samme rekkefølge som Søk1 er postene allerede sortert, og brukeren slipper å vente på at de skal bli sortert og systemet vårt slipper å bruke krefter på å gjenta sorteringen. La oss så si at den som utførte Søk2 utfører det samme søket en gang til, men ber om å få postene sortert på en annen måte. Nå er ikke mellomlageret med de sorterte postene til noen hjelp, men vi har fortsatt den opprinnelige trefflista mellomlagret og kan hente denne fra mellomlagret og sortere den etter brukerens ønske, uten at vedkommende trenger å vente på at postene skal hentes på nytt fra søketjeneren.

Hvor lang tid poster skal lagres i mellomlageret er et åpent spørsmål. Lagres de for lenge vil ikke endringer i de opprinnelige postene (nye, slettede og/eller endrede poster) reflekteres i søkeresultatene. Lagres de for kort vil ikke mellomlagringen ha noen effekt, fordi resultatene «går ut på dato» før det rekker å komme et nytt søk som kan dra nytte av det gamle. I utgangspunktet er levetiden til mellomlageret satt til et døgn, men dette kan endres gjennom konfigurasjonsvariabler. På sikt bør det antagelig implementeres et logg-system som viser hvilke søk som blir utført og i hvilken grad memmomlagringen faktisk kommer til nytte.

Mellomlagringen i Glitre bygger på PEAR-modulen Cache_Lite.

Blogg på WordPress.com.