Menu
▾
▴
Re: [Apc-aa-coders] Site.php3: nocache and cache invalidation
|
From: Mitra <mi...@mi...> - 2003-01-06 02:10:30
|
Hi Honza
There are two cases we are talking about here.
1: Where a change in a change in any slice used by a site needs to
invalidate the site. This seems to work fine.
2: Where changes to the site structure - e.g. the Spot's and Options
- should change anything cached for that Site - it does NOT need to
change things for the other Slices, since those slices internal views
haven't been changed. For this the change I made to site/index.php3
is necessary and sufficient, otherwise when editing site parameters
the old output is returned from the cache and is wrong.
While I don't agree with you that you need to invalidate cache for
other slices in mod_edit.php3, i.e. changes to a site cannot effect
component slices. I have not touched that code.
Also - note that 10 mins is the DEFAULT timeout, but a comment
somewhere says you can set it to much longer BECAUSE of cache
invalidation. To get around apc-aa being VERY SLOW in some complex
cases we have this set to about 2 days on our installation, which is
why I care about invalidation being done correctly!
- Mitra
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 against
>> nocache when doing a store.
>>
>> If I understand the logic, shouldn't nocache ONLY apply to retrieving
>> from the cache.
>>
>> I.e. when you do a retrieve you set nocache, and it would ignore the
>> cached value of the page, but would then cache the new, correct, page?
>
>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 is
>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 which
>> 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
> # 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 invalidate
> 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 slice 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 our
>case.
>
>The invalidateFor function looks for all cache records wich contains the
>string 'slice_id=3D16166...' in str2find field (so probably holds any
>information from the given slice) and invalidates such records (deletes
>it).
>
>Back to the Mitra's question:
>
>> Am I correct in assuming that invalidate call in modedit.php3:139 is
>> buggy, and that I should add the code
>>
>> $cache =3D new PageCache($db,CACHE_TTL,CACHE_PURGE_FREQ); # database=
changed -
>> $cache->invalidate("slice_id=3D".site_id); # invalidate old cached v=
alues
>>
>> 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 probably
>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 script
>is the invalidation much clever. There we use $slices4cache array which
>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=3D9e9acc045677619191
>191256ac7cd2ac,slice_id=3D04280ba6756556a6dd802607a3b0edd9,slice_id=3D8ce3
>8f43331abd2e555c533795313851,slice_id=3D6563656767536f6e6e6563742e2e2e2e"
>
>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
--
Mitra Technology Consulting - www.mitra.biz - mi...@mi...
02-6684-8096 or 0414-648-0722
Life is a Mystery to be Lived, not a Problem to be Solved
|
