Menu
▾
▴
Re: [Apc-aa-coders] Site.php3: nocache and cache invalidation
|
From: Mitra <mi...@mi...> - 2003-01-06 22:02:31
|
No - I havent' seen any problems with the long delays - but I haven't
looked for the expiry problem, that might be an issue., but none of
the expiry dates are critical on my sites - they are basically used
just as a way to reduce clutter, i.e. delete older items.
- Mitra
At 8:50 PM +0100 6/1/03, Honza Malik wrote:
> > 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.
>
>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
>> 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!
>
>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
>>
>>
>>
>>
>> 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 agains=
t
> > >> 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, pag=
e?
>> >
>> >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 invalidat=
e
>> > 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 ou=
r
>> >case.
>> >
>> >The invalidateFor function looks for all cache records wich contains th=
e
>> >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 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 probab=
ly
>> >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=3D9e9acc045677619=
191
>> >191256ac7cd2ac,slice_id=3D04280ba6756556a6dd802607a3b0edd9,slice_id=3D8=
ce3
>> >8f43331abd2e555c533795313851,slice_id=3D6563656767536f6e6e6563742e2e2e2=
e"
>> >
>> >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
>>
>
>
>
>-------------------------------------------------------
>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
|
