Re: [Apc-aa-coders] Site.php3: nocache and cache invalidation

[Honza M. <hon...@ec...>]

> There are two cases we are talking about here.
>=20
> 1: Where a change in a change in any slice used by a site needs to=20
> invalidate the site. This seems to work fine.
>=20
> 2: Where changes to the site structure - e.g. the Spot's and Options=20
> - should change anything cached for that Site - it does NOT need to=20
> change things for the other Slices, since those slices internal views=20
> haven't been changed. For this the change I  made to site/index.php3=20
> is necessary and sufficient, otherwise when editing site parameters=20
> the old output is returned from the cache and is wrong.

Right. For this solution you also have to add the site_id into
$slices4cache array in site_*.php3 script, I think, but it is OK. Good
solution.

> While I don't agree with you that you need to invalidate cache for=20
> other slices in mod_edit.php3, i.e. changes to a site cannot effect=20
> component slices. I have not touched that code.
>=20
> Also - note that 10 mins is the DEFAULT timeout, but a comment=20
> somewhere says you can set it to much longer BECAUSE of cache=20
> invalidation.  To get around apc-aa being VERY SLOW in some complex=20
> cases we have this set to about 2 days on our installation, which is=20
> why I care about invalidation being done correctly!

Oh, 2 days - It's nice to read it works with so long cache time. Do you
have any experiences/problems with such settings?

I suppose there could be small problem with 'expiry date' - there could
be items which is visible 2 days longer, than expected on the public
website.

   Honza

> - Mitra
>=20
>=20
>=20
>=20
> At 10:28 PM +0100 5/1/03, Honza Malik wrote:
> >On =DAt, 2002-12-31 at 07:52, Mitra wrote:
> >>  I've had some weirdness with old versions of pages being retrieved
> >>  from the cache.
> >>
> >>  One thing i notice is that on line 101 of slice.php3 it tests again=
st
> >>  nocache when doing a store.
> >>
> >>  If I understand the logic, shouldn't nocache ONLY apply to retrievi=
ng
> >>  from the cache.
> >>
> >>  I.e. when you do a retrieve you set nocache, and it would ignore th=
e
> >>  cached value of the page, but would then cache the new, correct, pa=
ge?
> >
> >No, nocache parameter is intended to use really no cache. Nor for get,
> >nor for store. I offten use noceche parameter for debuging and there i=
s
> >good oportunity to store some debug messages into chache, if we
> >implement nocache parameter another way.
> >
> >If you want, you can implement 'renewcache' parameter or such, which
> >will behave as you describe.
> >
> >>  It looks like the cache isn't being invalidated as the Spot's are
> >>  being changed, this appears to be happening in site/index.php3 whic=
h
> >>  doesn't appear to be doing any cache invalidation.
> >>
> >>  I'm not sure how to invalidate the cache, since the example I find =
-
> >>  site/modedit.php3:139  seems (if I understand things correctly) to
> >>  invalidate the cache for all slices, so I'm guessing I'm
> >>  misunderstanding something
> >
> >That's right - it is not optimal solution, but the only possible. The
> >modedit for site in not called so often, so I think we can invalidate
> >whole cache time to time.
> >
> >Explanation - how cache works:
> >
> >It uses folowing database structure:
> >   CREATE TABLE pagecache (
> >     id varchar(32) NOT NULL, # md5 crypted keystring used as database
> >                              # primary key (for quicker database  =20
> >                              # searching)
> >     str2find text NOT NULL,  # string used to find record on manual
> >                              # invalidation of cache record
> >                              # (- it could be keystring)
> >     content mediumtext,      # cached information
> >     stored bigint,           # timestamp of information storing
> >     flag int,                # flag - not used for now
> >   PRIMARY KEY (id), KEY (stored));
> >
> >Row example:
> >   id:       56b6dc163ea533b88227eee94b37bee4
> >   str2find: slice_id=3D11783cf03dbb66773c1219bd8b6f7456
> >   content:  <table width=3D"600"><tr><td colspan=3D3><br><font s...
> >   stored:   1041798783
> >   flag:     0
> >
> >
> >Basicaly - if you store something to the cache, you use
> >   $cache->store($keystring, $content, $str2find);
> >
> >where:
> >   $keystring is any string wich fully identifies the resulting
> >              content (it is all view's parameteres joined into string=
,
> >              for example). There is called md5() on $keystring before=
 it
> >              is stored into database, so the search for the keystring=
 is
> >              then much quicker.
> >
> >   $content   is the content which should be generated for $keystring
> >
> >   $str2find  is some string, which we can use, if we want to invalida=
te
> >              some specific cache content
> >
> >So, if we want to store content of view from slice 16166... we set
> >$str2find =3D 'slice_id=3D16166...'. Everytime the content of any slic=
e is
> >changed (new item added, any item in the slice is changed, moved, ...)
> >the function:
> >   $cache->invalidateFor($cond)
> >is AUTOMATICALY called by AA, where $cond=3D'slice_id=3D16166...' in o=
ur
> >case.
> >
> >The invalidateFor function looks for all cache records wich contains t=
he
> >string 'slice_id=3D16166...' in str2find field (so probably holds any
> >information from the given slice) and invalidates such records (delete=
s
> >it).
> >
> >Back to the Mitra's question:
> >
> >>  Am I correct in assuming that invalidate call in modedit.php3:139 i=
s
> >>  buggy, and that I should add the code
> >>
> >>  $cache =3D new PageCache($db,CACHE_TTL,CACHE_PURGE_FREQ); # databas=
e changed -
> >>     $cache->invalidate("slice_id=3D".site_id);  # invalidate old cac=
hed values
> >>
> >>  into index.php3.
> >
> >Not at all - it is not enough. Site module uses outputs from many
> >slices/viws, but the site itself do not know, which all slices it uses.
> >So, if we invalidate cache just for "slice_id=3D".site_id, there proba=
bly
> >remain cached some views, which is used in the site. Such views could
> >have old values, so if we want to be sure, we have to invalidate whole
> >cache.
> >
> >I have to note, this is ONLY the case of changing parameters in site
> >module settings which is called really seldom. In main site.php3 scrip=
t
> >is the invalidation much clever. There we use $slices4cache array whic=
h
> >lists all slices used in the site:
> >
> >$slices4cache =3D
> >   array( "cee194633366705889fd2f58d428ec05", // Ecn - events'
> >          "9e9acc045677619191191256ac7cd2ac", // Ecn - authors'
> >          "04280ba6756556a6dd802607a3b0edd9", // Ecn - banners'
> >          "8ce38f43331abd2e555c533795313851", // Ecn - prices'
> >          "6563656767536f6e6e6563742e2e2e2e", // Ecn - about'
> >          ...);
> >
> >Then we can use str2find string just like:
> >
> >"slice_id=3Dcee194633366705889fd2f58d428ec05,slice_id=3D9e9acc04567761=
9191
> >191256ac7cd2ac,slice_id=3D04280ba6756556a6dd802607a3b0edd9,slice_id=3D=
8ce3
> >8f43331abd2e555c533795313851,slice_id=3D6563656767536f6e6e6563742e2e2e=
2e"
> >
> >so any change in any listed slice leads to invalidation of the chache
> >for the current site (which uses this slice, of course).
> >
> >Last note: all values are cached for maximum 10 minutes (see CACHE_TTL
> >parameter in config.php3)
> >
> >    Honza
> >
> >
> >
> >>  I've done this - and it appears to work - but I wanted to check I'm
> >>  understanding the cache logic correctly before I commit to CVS.
> >>
> >>  - Mitra
> >>
> >>
> >
> >
> >
> >-------------------------------------------------------
> >This sf.net email is sponsored by:ThinkGeek
> >Welcome to geek heaven.
> >http://thinkgeek.com/sf
> >_______________________________________________
> >Apc-aa-coders mailing list
> >Apc...@li...
> >https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
>=20